Passing control away and back again

[Graham Samuel]

Just to say, that there is absolutely nothing wrong in using a modal stack to stop the action until the user had done their input - I now see that for the case I outlined, it’s the preferred way to go. What it does (apart from the obvious grabbing of control and keeping a grip on it) is to treat the activity of the modal stack as if it was a handler in the message path. What I was trying to express in my earlier mails (in part) was the issue that if you ‘go to’ somewhere in LC, you lose the ability to go back, since the ‘go to’ is not a call to a handler in the same sense. This is perhaps of more interest to students of program structures than practical developers (hence my original reference to Dijkstra). Anyway thanks for all the discussion that this topic stirred up.

Graham

> On 15 Feb 2015, at 19:07, Peter Haworth <pete at lcsql.com> wrote:
> 
> The -1 trick is new to me, good to know.
> 
> What's the problem with using a modal stack as suggested by Doc Hawkins?
> The initial code waits until the modal stack closes before continuing -
> isn't that the requirement?
> 
> As for where to put the startup code, card 1 of the main stack has always
> worked for me.  It executes every time the main stack is opened but not
> when other stacks are opened.
> 
> 
> On Sun Feb 15 2015 at 8:56:21 AM J. Landman Gay <jacque at hyperactivesw.com>
> wrote:
> 
>> On February 15, 2015 10:41:42 AM CST, Paul Dupuis <paul at researchware.com>
>> wrote:
>>> On 2/15/2015 10:02 AM, Graham Samuel wrote:
>>>> 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.
>>> 
>>> send <message> to <object> -- is like a call. The handler waits until
>>> message is executed before proceeding to the next statement
>>> 
>>> send <message> to <object> in <time> -- places the message in the
>>> message queue and the handler continues. The message queue then invokes
>>> the message in the allotted time.
>>> 
>>> So,
>>> 
>>> on mouseUp
>>> close this stack
>>> send "doPart2" to <main stack>
>>> end mouseUp
>>> 
>>> will not do what you want as the send executes "doPart2" and the
>>> completes the mouseUp, but
>>> 
>>> on mouseUp
>>> close this stack
>>> send "doPart2" to <main stack> in 10 milliseconds -- or some non-zero
>>> time
>>> end mouseUp
>>> 
>>> causes doPart2 to execute in the context of the main stack AFTER the
>>> mouseUp handler has completed.
>>> 
>>> If I recall correctly, Richard Gaskin produced an excellent short 1 or
>>> 2
>>> page guide on message passing in LiveCode. A *must have* reference if
>>> you're still learning all the ins and outs. It looks like he's expanded
>>> it from the one I remember as well. See
>>> http://www.fourthworld.com/embassy/articles/revolution_message_path.html
>>> 
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> Actually you can send in 0, which will execute right after the handler
>> completes, or even in - 1 which pushes the request to the front of the
>> queue ahead of all other pending messages. I learned that last trick from
>> Dar a while back.
>> --
>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>> HyperActive Software           |     http://www.hyperactivesw.com
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode