Page 5 of 6

Re: Answer function

Posted: Sat Nov 14, 2020 11:01 pm
by FourthWorld
Curious. That's an engine thing I presume?

Re: Answer function

Posted: Sat Nov 14, 2020 11:31 pm
by stam
could someone post an example of a modal stack leaking mouseDown messages? (just for my own curiosity, as when i test this i can't make it happen...)
Just for curiosity's sake...

Re: Answer function

Posted: Sat Nov 14, 2020 11:48 pm
by mwieder
I've got a sample stack in the bug report linked to earlier.

Re: Answer function

Posted: Sat Nov 14, 2020 11:56 pm
by stam
mwieder wrote:
Sat Nov 14, 2020 11:48 pm
I've got a sample stack in the bug report linked to earlier.
Yeh except that doesn't replicate the problem either.

I presume you're referring to this: https://quality.livecode.com/show_bug.cgi?id=22977
I downloaded the test stack. Using either "no substack" or "substack" and clicking on either the buttons in the modal does not trigger a breakpoint for me... ever.

Not sure what's different with my setup other than i've probably used this a lot less than most of you, haven't modified anything and am probably using many fewer plugins...

Re: Answer function

Posted: Sun Nov 15, 2020 12:28 am
by mwieder
Got it. There's now an updated test stack there that will avoid debugger issues and just place some text in the message box.

Re: Answer function

Posted: Sun Nov 15, 2020 12:32 am
by mwieder
Richard- was that last question aimed at me? From the dictionary:
The modal command pauses the running handler until the
modal dialog box is dismissed (usually by clicking a button in the
modal dialog box).
and
While a modal dialog box is open, other windows cannot be edited or
brought to the front. Because of this, you should use modal dialog boxes
only when a stack must obtain feedback from the user before it can
continue.

Re: Answer function

Posted: Sun Nov 15, 2020 12:55 am
by FourthWorld
Thanks, Mark. Both of those are good descriptions, but do not address what's being referred to as "message leaking" (what we usually call "normal message path").

The first snippet says the calling handler is blocked, which seems to be happening in this test case so that much is fine.

The second refers to the behavior of a fully modal window, but doesn't say all system messages are suspended.

What am I missing?

Re: Answer function

Posted: Sun Nov 15, 2020 2:23 am
by mwieder
Er...they're not "suspended", they're just contained within the modal dialog.
So you can press keys in an Ask dialog and they're handled, but pressing keys in any other stack or control has no effect.
Modal dialogs force the user to interact with them before they can do anything else. I even have a hard time envisioning a use case for user-generated modal dialogs that need to handle system messages outside the modal stack itself.

MouseMove messages are also leaked from Answer and Ask modal stacks but I think that's an even more obscure edge case.

Re: Answer function

Posted: Sun Nov 15, 2020 3:05 am
by FourthWorld
Yes, I'd expect key events to go to the topmost stack. But that's not specific to modals.

Maybe I need better coffee to catch up with what you're saying.

Re: Answer function

Posted: Sun Nov 15, 2020 3:34 am
by dunbarx
Just to throw a monkey wrench into the mix.

The "mouseMove" message is sent while a modal dialog is open, but ONLY when the cursor leaves the dialog. On a new card with a button and a field. in the button script:

Code: Select all

on mouseUp,
   answer "ff"
end mouseUp
in the card script:

Code: Select all

on mouseMove
   put random(99999) into fld 1
end mouseMove
Open the answer dialog. Now move the cursor in and out of the dialog. I t does not matter if the dialog is far away form the card. A new number appears in fld 1 each time the "MouseLeaveFromDialogInvokesMouseMoveOnce" message is sent. By the way, I could not find this message in the dictionary. Is it undocumented?

Now, then, change the card script to:

Code: Select all

on mouseLeave
   put random(99999) into fld 1
end mouseLeave
Open the dialog, and you will find that if you move the cursor out of the card window and into the dialog window, one random number is generated into fld 1. If you only simply leave the card window, nothing. If you just leave the dialog window, nothing. You have to leave the card window and then enter the dialog window to invoke the "mouseLeaveButOnlywhenLaterEnteringAnaswerDialog" message.

I could not find this one either.

How many other messages, however distorted in their action, likely each with its own pecadillos, are associated with an open dialog?

Craig

Re: Answer function

Posted: Sun Nov 15, 2020 3:47 am
by mwieder
Craig- mouseLeave is necessary for the functioning of the ecosystem. You may find the cursor changes when over a stack etc.

And if you trap the mouseMove message in a library stack you'll see it's in use within a modal dialog as well. Again, it's necessary for the functioning of the system as a whole, i.e., you'd want to cursor to move when you move the mouse, and you shouldn't need to write code to handle that in each modal dialog script.

Re: Answer function

Posted: Sun Nov 15, 2020 3:48 am
by FourthWorld
dunbarx wrote:
Sun Nov 15, 2020 3:34 am
How many other messages, however distorted in their action, likely each with its own pecadillos, are associated with an open dialog?
I would imagine all of them except those needed to maintain the modality of the dialog.

Re: Answer function

Posted: Sun Nov 15, 2020 3:53 am
by dunbarx
Richard. I understood this from earlier.

But there are no stacksInUse in my example. The "messages", such as they are, live entirely within a card and the dialog stack itself.

Or did I miss the fact that a stackInUse (library stack) was necessary to see the oddities of the last five pages?

Craig

Re: Answer function

Posted: Sun Nov 15, 2020 3:57 am
by mwieder
Craig- yes, that's the whole point of this topic.

Re: Answer function

Posted: Sun Nov 15, 2020 4:24 am
by stam
mwieder wrote:
Sun Nov 15, 2020 12:28 am
Got it. There's now an updated test stack there that will avoid debugger issues and just place some text in the message box.
Yep that did it...

Not sure i understand why putting the same mouseDown code in the parent stack doesn't trigger the same issue, it's only for the stack you've set to 'start using' -- can't quite get my head around the message path there. But certainly proves your point about the answer dialog 'leaking'.