What I do is I have setup cards. One for preferences, another for setting up
the database etc. In the card script of each setup card, I have a script local
variable, which when the stack is first opened will be empty. So in the
openstack handler in the mainstack, I lock the screen, then go to each card
that needs to initialize, check that script local variable, launch
initialization procedures if empty, set them to some value (I use true) and
then I go back at the end of the initialization if everything goes smoothly.
Now if I have to stop and get information from the user, then I put a home
button on the card so the user can go back to the first card of the stack. For
instance, if I go to the database setup card, and everything is in order, I
have scripts that initialize my sqlYoga setup, open a socket to test the
connection, connect and disconnect with the database, then go back.
Another example is in my preferences card on one particular application, I
require either Adobe Acrobat or Reader be installed. If I cannot find it in the
usual place(s) I ask the user to locate it for me. If the user fails to find
it, I set the local initialization variable to false and alert the user that
some features will not be enabled until they install the Adobe product
necessary.
Further, if I need to save anything (like the current connection object) I save
that in a property of the mainStack. That way I can always get it from any
substacks I have open, (since the mainstack of any substack is always open) and
the card will work the same way with any application I write.
I also have library scripts stored in hidden buttons on each card that I insert
into the back when that particular card initializes. For instance, my Database
Setup card has such a library of database oriented command and functions. Going
to that card inserts the script of that button in the back. The net effect of
all this is that my cards are modular, meaning I can paste them into any stack
and it will always work the same way. Simply by going to the card, everything
is set up and taken care of.
Bob S
> On Feb 15, 2015, at 04:37 , Paul Dupuis <p...@researchware.com> wrote:
>
> On 2/15/2015 7:14 AM, Graham Samuel wrote:
>> This is probably very dumb, but I've got into a muddle thinking about " 'Go
>> To' Considered Harmful", if anyone is old enough to remember that Dutch
>> utterance... anyway:
>>
>> In LC, really everything is dealt with in handlers which begin, execute and
>> end and can be nested within one another. So how do you construct a control
>> structure like the following:
>>
>> 1. The program starts up with a 'startup' handler (could use 'preOpenStack'
>> but it's not so good). The script there does setting-up things, and then it
>> notices that it needs extensive user input (for example, maybe the program
>> isn't registered and we need some details - even maybe payment) before we
>> can go on.
>>
>> 2. To get the user input, the script does a 'go to' (which is really an
>> 'open') to a special stack for this input. Eventually, the data is input and
>> checked, and the user clicks say an "OK" button to get back to the startup
>> process.
>>
>> 3. What happens now? The script can't easily resume the original startup
>> handler, can it? After all, the special stack which deals with user input is
>> not a handler nested within the startup handler. The "OK" button is driven
>> by a 'mouseUp' handler, but when that handler closes, there is no automatic
>> way of going back to the calling handler of the whole process (the startup
>> handler) due to the lack of nesting. What the script **can** do is to invoke
>> a further handler in the original card where the startup is, called perhaps
>> 'continueStartup', so that at the end of the 'mouseUp' script, we simply
>> call this new handler.
>>
>> This kind of works, but we are left with loose ends: the original 'startup'
>> handler never reaches its termination point ('end startUp') as far as I can
>> see, and the 'resume' script doesn't exactly terminate either, does it? If
>> it did, we'd end up in the 'mouseUp' script in a stack (window), which is
>> probably closed by now, having done its job. So viewed as a set of control
>> structures, it looks a mess.
>>
>> OK, there is a way of doing it, kind of, but what is the most logical way to
>> approach this problem of non-nested control structures?
>>
>>
>
> If you code looked like this:
>
> on startup
> <part 1 code>
> if <some condition> then
> open stack <user input stack>
> exit startUp
> end if
> <part 2 code>
> end startup
>
> and your <user input stack> exits in a mouseUp handler such as
>
> on mouseUp
> close this stack
> end mouseUp
>
> you would need to restructure you code like this:
>
> on startUp
> doPart1
> if <some condition> then
> open stack <user input stack>
> exit startup
> end if
> doPart2
> end startup
>
> on doPart1
> <part 1 code>
> end doPart1
>
> on doPart2
> <part 2 code>
> end doPart2
>
> and the <user input stack> mouseUp handler would be modified as
> on mouseUp
> close this stack
> send "doPart2" to <main stack> in 1 tick
> end mouseUp
>
> This places the <part 1 code> and <part 2 code> blocks in separate
> handlers in the main stack so that the <part 2 code> handler can be
> invoked from the mouseUp on the input stack.
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
