I’ll admit my explanation wasn’t as thorough as it should have been. I was 
thinking along the same lines as Paul though, splitting the startup procedure 
in appropriate parts as sub handlers which could be performed individually. 
Instead of opening another stack if certain criteria were met, you could opt to 
go to a card in the stack itself, where the user could enter the information 
needed to complete the start up procedure. Then you would not need to use send 
when finalising the procedure. You would only need to call the <part 2> code 
from the mouseUp handler on the “input card” and then go to whichever card you 
like. 


Tore


> 15. feb. 2015 kl. 16.02 skrev Graham Samuel <livf...@mac.com>:
> 
> Tore and Paul thanks for your ultra-rapid replies - and on a Sunday, too!
> 
> Actually I don't understand Tore's solution at all, sorry. I simply can't 
> follow what structure is being suggested. (As and aside, I don't want to use 
> a 'preOpenStack' stack script because I want a script that is executed 
> exactly once when the app is originally started, and 'startUp' is a 
> specialised message for doing just that. 'preOpenStack' is executed every 
> time a stack is opened, which in some circumstances could be inappropriate.)
> 
> But I do understand Paul's, which was very near the approach I was thinking 
> of taking myself. I suppose I am still worried about the 'send'. Sending 
> isn't calling, is it? I mean, in principle, a handler like "dopart2" in 
> Paul's example will be executed, and then control will return to the script 
> that executed the 'send', won't it? So we end up executing "end mouseUp" in 
> the context of the button that was clicked, not the script that was running 
> in the 'startUp' handler. Perhaps this doesn't matter, but this is the issue 
> I'm trying to get my head around. Anyway it's a viable solution and I'm 
> grateful.
> 
> Graham
> 
>> On 15 Feb 2015, at 13:37, Paul Dupuis <p...@researchware.com> wrote:
>> 
>> 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.
> 
> 
>> On 15 Feb 2015, at 13:27, Tore Nilsen <tore.nil...@me.com> wrote:
>> 
>> Why don’t you just register the missing parts in a variabel, go on with the 
>> preOpenStack script and then, depending on what is missing, go to a card 
>> where the user then can enter the information needed. When the information 
>> is registered the user will be taken to the application itself with all the 
>> information in place. 
>> 
>> Tore N
>> 
>>> 15. feb. 2015 kl. 13.14 skrev Graham Samuel <livf...@mac.com>:
>>> 
>>> 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?
>>> 
>>> TIA for any thoughts
>>> 
>>> Graham
> 
> 
> _______________________________________________
> 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

Reply via email to