Passing control away and back again

[Paul Dupuis]

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.