Passing control away and back again

[Peter M. Brigham]

You mention saving something in a property of the mainStack. So I assume you are running this in the IDE not as a standalone, since the mainStack in a standalone can't be changed and then saved? Or maybe I'm missing something?

-- Peter

Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig

On Feb 16, 2015, at 6:45 PM, Bob Sneidar wrote:

> 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 <paul at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode