A possible messaging and modal dialog bug...

dunbarx at aol.com dunbarx at aol.com
Fri Feb 26 18:23:07 EST 2016


Paul.


With the "in time" removed. I get two dialogs, one after the other, telling me "dialog 1' has fired, and then "Dialog 2". The field fills as advertised. v.6.7 on OS 10.9.


Craig



-----Original Message-----
From: Paul Dupuis <paul at researchware.com>
To: use-livecode <use-livecode at lists.runrev.com>
Sent: Fri, Feb 26, 2016 5:27 pm
Subject: Re: A possible messaging and modal dialog bug...

Craig,

If you are referring to the note that says:
---------------
Important!  Specifying a time can affect the order in which statements
are executed. If you don't specify a time, the message is sent
immediately, and any handler it triggers is completed before the rest of
the current handler is executed. If you use the send in time form of the
send command--even if you specify a time of zero seconds--the current
handler finishes executing before the message is sent.
--------------

I understand that. This "bug" surfaced in a publish and subscribe system
that is used to allow analytical modules to subscribe to messages
(internal to the application) that are generated when various data
elements are changed.

The issue is not the order that things execute. The order should be (1)
the mouseUp handled ends [because I used send .. in time], then btn 1
receives the "dataChanged" message and LC should execute that handler to
completion, then I would have expected btn 2 to have received and
execute its dataChanged message.

What is unexpected is that the answer statement in the script of btn 2
is NEVER executed! This seems like a BUG.

What must be happening is that when the answer dialog is up (from btn 1)
and equivalent of 'wait with messages" is occuring, so btn 2 then gets
the "dataChanged" message from the pendingMessages and starts to
execute. The puzzling behavior is that when the script of btn 2 gets to
the answer statement, presumably because the answer dialog is already
open, it just continues to the next statement. This seems wrong to me.

I have not tried this with, say my own modal dialog using the 'modal'
command. I wonder if the same problem exists. In otherwords, if a Modal
window is open and some other script tries to execute a model
window/dialog, should that script pause until the first modal window is
closed? Instead it just skips to the next code line. This can lead to
error and unexpected results.

Then again, someone at LiveCode that understands the messaging system
like Mark or Peter may have an explanation of why this should be the
expected behavior?

On 2/26/2016 4:17 PM, dunbarx at aol.com wrote:
> Paul.
>
>
> The dictionary warns against sending messages in time. See the notes at the bottom. If you lose that portion of your handler, the action proceeds normally.
>
>
> Craig Newman
>
>
>
>
> on mouseUp
>   send "dataChanged" to btn 1 in 5 milliseconds
>   send "dataChanged" to btn 2 in 10 milliseconds
> end mouseUp
>
>
>
>
> -----Original Message-----
> From: Paul Dupuis <paul at researchware.com>
> To: LiveCode Developer List <livecode-dev at lists.runrev.com>; use-livecode <use-livecode at lists.runrev.com>
> Sent: Fri, Feb 26, 2016 2:33 pm
> Subject: A possible messaging and modal dialog bug...
>
> I what seems to me is a "bug" related to messages and model dialogs in
> LiveCode. I have tested this under LC676, LC7.1.1, and LC8.0.0dp15
>
> If I have stack with 2 buttons, called Dialog1 and Dialog2 with the
> following script in each button.
>
> on dataChanged
>   put short name of me & colon & cr & "BEFORE DIALOG" & cr after fld 1
>   answer "Message Received by"&& short name of me && "at"&&the milliseconds
>   put short name of me & colon & cr & "AFTER DIALOG" & cr after fld 1
> end dataChanged
>
> A single scrolling field to see results (fld 1) and a 3rd button with a
> script:
>
> on mouseUp
>   send "dataChanged" to btn 1 in 5 milliseconds
>   send "dataChanged" to btn 2 in 10 milliseconds
> end mouseUp
>
> When you click on the 3rd button, button 1 receives the dataChanged
> message, places the data and "BEFORE DIALOG" note in the field and then
> presents the answer dialog and suspends pending the dialog.
> While button 1's modal dialog is still waiting for a user action, button
> 2 gets its dataChanged message, places the short name and it's BEFORE
> DIALOG note and the skips its answer dialog and places its (button 2)
> AFTER DIALOG message and exits.
> Then when the visible Answer dialog is responded to from Button 1's
> script, button 1 places its "AFTER DIALOG note in the field.
>
> This is counter to what I would expect. I would have expected EITHER:
> the script in button 2 to have suspended as soon as it received its
> message and not executed until the answer dialog from button 1 was
> responded to
> OR
> the script in button 2 to have suspended when it reached the answer
> statement and when the answer dialog from button 1 was complete, then
> you would get the answer dialog from button 2.
>
> The fact Livecode SKIPs a line of code (the answer statement in button
> 2) with no error or warnings or anything I find disturbing?
>
> Is this a BUG or an expected behavior? If there any way to ensure any
> dialog in a message executed in time while another dialog is pending
> does not get skipped?
>
>
> _______________________________________________
> 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
>


_______________________________________________
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




More information about the Use-livecode mailing list