Dispatch / Send / Wait with/without Messages

[Ralph DiMola]

I'm having the same epiphany as Paul did below. The cornucopia of
flexibility(and gotchas) that LC's message path model provides using:
1) Standard issue calling of commands and functions.
2) Engine messages
3) Send (optionally in time)
4) Dispatch
5) Wait in time with/without messages
6) exit to top

And any others that I left out or don't know about can do things that I
never could have imagined when I first found LC. Although I use all the
above there's probably combinations I can't wrap my head around without more
info. This would be a great as a dedicated chapter in a book and/or a Dr
Mark W symposium followed by Q&A at the next RR Live. There seems to be a
lot of app power/error prevention in the message path gold. For a newbie the
LCs message path gold would be very attractive if it was only well
documented and advertised.

My 2 cents...

Now back to changing some "wait with messages" to plain old waits to prevent
users from clicking and getting my code into trouble now-and-again.

Thanks to all on the list for this info!!!

Ralph DiMola
IT Director
Evergreen Information Services
rdimola at evergreeninfo.net


-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf
Of Bob Sneidar via use-livecode
Sent: Wednesday, August 03, 2022 12:15 PM
To: How to use LiveCode
Cc: Bob Sneidar
Subject: Re: Dispatch

One correction. If a value is returned by the handler that was called, the
result will be that value. 

Bob S


> On Aug 3, 2022, at 08:53 , Mark Wieder via use-livecode
<use-livecode at lists.runrev.com> wrote:
> 
> One, if I'm calling a handler in a different object that is outside the
normal message path then I'll dispatch the handler to that object rather
than using send. One caveat: note that the dispatch command returns a
three-state value: "handled", "unhandled", and "passed". So on checking the
return value I use "if it it not unhandled then...". The advantage is that
there's no runtime error if the command isn't caught, at the slight
disadvantage of having to check whether it was handled.


On 7/30/2022 3:53 PM, Paul Dupuis via use-livecode wrote:
> My understanding of 'wait 0 with messages' is that it will cause any 
> pending messages, that are not scheduled for a time later than the 
> current time, in the pendingMessages queue to be processed before 
> continuing. Messages later than the current time (when the statement 
> is executed) will not be processed (yet).
>
> Is this correct?
>

First, than you to those that have responded.

The reason I got curious about 'wait 0 with messages' (or even just 'wait
0') is because of an epiphany I had just last week regarding a bug a
customer reported in our software. The customer experienced and execution
error and our software presents a custom dialog that allows them to email
out support account some information, including the 'executionContexts' so
we have some code debugging information.

The problem as a 'can't find object' error. In reviewing the code, I could
see no way that the error should have occurred. The code was using the
ChartMaker library to create a graph. It all looked good per documentation
and we could not reproduce the error in house. I then noticed a 'wait 0 with
messages' prior to the line the error occurred on and noticed that the line
that had the error used object references relative to the current stack
(which the defaultStack was explicitly set to much prior).

My epiphany was realizing - for the first time, despite LiveCodeing since
HyperCard and having a Masters in Computer Science and my entire career
being in the IT/software development space for over 40 years - that when the
'wait 0 with messages' is executed, if there was a pending USER click on
another window, the defaultStack could change and then the relative object
references would not be able to find their target objects.

Perhaps I should have realized that a 'wait 0 with messages' COULD result in
the defaultStack changing much sooner OR perhaps I should always fully
qualify all object references (which I have been doing for quite a few
years, but this was old code), but it is a 'gotcha' of using wait with
messages I had never thought of.

The Dictionary Entry (LC 9.6.8) does state "If the wait..with messages form
is used, LiveCode continues normal processing during the wait. The current
handler is frozen, but the user can start other handlers and perform other
actions such as switching cards." and 'switching cards' 
does imply changing the context of relative object references even if the
defaultStack does not change, so perhaps I should have realized, but didn't
until just last week.

Now I am very curious about exactly what wait 0 with messages does and also
about what actions change the defaultStack. Does anyone know of an article
or something someone has done to identify all the messages, commands, or
functions that change (or potentially change) the defaultStack?



_______________________________________________
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