Or he could be just trying to initialise each time the program is loaded, in which case things are fine.
Didn’t work for me of course, since I want to keep the data from the very first activation (registration data, for example) in between activations - which is what the Application Data space in operating systems is for. In my scheme I just store a text file in this area, but people often use a stack, again fine as long as it isn’t the one used to make the standalone. A variation on this is to keep a ‘clean’ copy of this user-modifiable stack in the read-only area where the standalone is stored. This gives an opportunity to offer the user a ‘reset’ function, where the clean stack is copied to the Application Data area to overwrite the one previously modified by the user. But I guess everyone knows this already. Graham > On 17 Feb 2015, at 02:41, Peter M. Brigham <pmb...@gmail.com> wrote: > > 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 _______________________________________________ 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
