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 pmb...@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 <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 _______________________________________________ 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
