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
