LiveCode Forums.

It took all of 30 seconds to fix things here in the Answer dialog stack script.
I'm happy to submit a PR for this and the Ask dialog, but the bug report has to be filed first.

...and I also want to point out that the Answer dialog does *not* leak the mouseDown message to the underlying card or stack, just to the stack in the "start using" list.

Its a fairly obscure fault which is unlikely to affect most users. I was unlucky in that the spurious mouseDown threw me into a section of code that just caused a lockup rather than doing something obvious. It just happened to catch me out - not yet being too familiar with LC, and took a few days to figure out. If it was documented it would be easy to dial out.

odysseus wrote: Sat Nov 14, 2020 2:31 pm If it was documented it would be easy to dial out.

One of the challenges with addressing an issue through documentation is figuring out where to put the note.

In your journey, would a note in the Dictionary entry for "start using" have helped?

I wish to post the silly notion that maybe documenting a bug is not the same as fixing it.
Plus I believe the work involved in trying to document this is more involved than the fix, which is filed here:

https://quality.livecode.com/show_bug.cgi?id=22977

mwieder wrote: Sat Nov 14, 2020 4:54 pm I wish to post the silly notion that maybe documenting a bug is not the same as fixing it.
Plus I believe the work involved in trying to document this is more involved than the fix, which is filed here:

https://quality.livecode.com/show_bug.cgi?id=22977

Thank you for submitting that bug report.

It's certainly better to handle even exotic edge cases than to just let them go.

But the underlying nature of the problem here isn't limited to one message in two dialogs. Ultimately we may see a similar rate of incidence (fortunately just 1 report in 20 years) for just about any message not trapped by an IDE or plugin component that's handled in a script the developer chose to make global in scope.

So while we ponder how we'll preempt the forum thread we'll see in 2040 about mouseDowns not being trapped in the Inspector, we may also consider an additional step that has value:

Where in the documentation would be the best place to remind people of the implications of handling system messages from global-scope scripts?

Cool stuff. But:

I also want to point out that the Answer dialog does *not* leak the mouseDown message to the underlying card or stack, just to the stack in the "start using" list.

Have I completely, since HC 2, misunderstood what a "stack in use" is? How does such an object, placed explicitly rather high (all right, already, "low") in the message hierarchy (and if several, "layered" in the order they were included) see a passed message before the card that owns the sending "answer" handler?

It appears the message is not so much passed as sent, skipping at least two ordinary hierarchy layers.

Craig

Craig-
Hmmm... that's an interesting point, and I don't have a good answer.

Richard -
How does a "start using" stack fit into your message hierarchy picture? It's not like a front- or back script because in our current case the card or stack script would be getting the message. Is this, as Craig suggests, a matter of the message being "sent" explicitly?

The dictionary says that a library or "start using" stack is placed in the message path after the stack and before backscripts, but that's not what's happening here. Does the fact that we're dealing with a modal stack affect the message path?

Ask and Answer dialogs live in a separate stack file while you're working in the IDE.

So anything in your stack script, or any other stack script, won't come into play - unless you make the script global as either a library or a backscript.

Doh! Of course - that makes sense.
OK - that's my stupid post for the day. Now I can take the rest of the day off.

But it would be an issue in a standalone. And in that scenario the problem is worse, since it's difficult to diagnose issues in a standalone, esp those that don't also occur in the IDE.

Doh, here, too.

And I so often spout that "everything is just a stack".

I guess I got lazy and complacent, thinking that those so very modal (sometimes maddeningly so) two dialogs seem so tightly bound to the card from which they appear. I felt (apparently not thought ) that everything concerned with them belonged ultimately to the card.

I think they should, though.

Craig

There are two things at play, related by the edge case uncovered here.

First, modal dialogs should not leak messages as side effects. If you bring up a modal dialog and try to click on some other stack to initiate a mouseDown message, nothing happens. And this is true whether or not there are library stacks or frontscripts in the message path. The modal stack blocks this activity. The fact that a library stack can still catch a mouseDown message in Answer and Ask dialogs means that the message is escaping from the modal dialog box down to the library stack level. This is a bug, duly reported, and can be verified by simply placing an empty mouseDown handler in the card scripts of both stacks and trying the experiment again.

(I *did* btw try mouseDown messages in the property inspector to validate that they aren't leaked there)

The other thing to deal with is documenting how intercepting system messages (or actually any messages) in frontscipts, behavior scripts, etc can mess with your perception of reality. That will probably take an entire document on its own. I'd start with your canonical message path document and add disclaimers with detailed examples.

I'm not quite getting how this is different in a standalone.

Why is the mode of the stack important?

Because modal stacks are supposed to block any other messages until you dismiss them, either by selecting one of the options or by canceling them. And they do, except as discovered, for mouseDown messages.