Need help with "disabling" a button!

[jacque]

That's correct behavior, events are queued during a wait. Since the button is re-enabled immediately after, it responds when the pending mouse events get sent.

MobileClearTouches will work, but it is a mobile-only command and will fail in the IDE. You can branch the handler to check for the environment and if it is mobile, use mobileClearTouches, otherwise use flushevents.

[karasyrup]

I see - it was the branching the handler to check for the environment piece that I was missing. That seems to work now, thanks jacque!!

[dunbarx]

I made a button with:

Code: Select all

on mouseUp
      disable me
      wait 2 seconds
      enable me
end mouseUp

Click on the button a few times quickly. Just watch.

@Jacque. Events are queued during wait, but a disabled button fires "mouseUp"? I did not know this, and do not get it.

Craig

[Klaus]

@Jacque. Events are queued during wait, but a disabled button fires "mouseUp"? I did not know this, and do not get it.

Same here!?

[dunbarx]

Jacque

Klaus and I comprise a formidable team of old and disgruntled LC'ers.

If one clicks on a disabled button, no messages are sent. Now then, if one clicks on a disabled button currently in the throes of a "wait" interval, all of a sudden messages are sent????

[jacque]

If one clicks a disabled button, the mouse event is still sent but it "passes through" the disabled object and moves on to any underlying object. In this case, the events are queued because a "wait" is in progress, ready to be sent as soon as the wait finishes. But at the same moment, the handler enables the button and so it catches the events instead of the object underneath.

I actually depend on mouse events triggering over a disabled object. In my case I have SVG graphics placed over buttons because they provide nicely scaleable icons. I disable the SVG so that mouse events will be caught by the underlying button. That works. But if I were to enable the SVG, it would catch the mouse clicks instead. Disabled objects do not prevent messages, they just act as though they aren't there.

[Klaus]

Disabled objects do not prevent messages, they just act as though they aren't there.

Oh boy, that's what we "old and disgruntled LC'ers" were talking about all the time!

[jacque]

Disabled objects do not prevent messages, they just act as though they aren't there.

Oh boy, that's what we "old and disgruntled LC'ers" were talking about all the time!

I'm confused now. I was disputing this:

Events are queued during wait, but a disabled button fires "mouseUp"?

The engine (not the object) sends messages regardles. Whether the object receives the message depends on its disabled state. If the button becomes enabled before the backup queue has completed, it will begin receiving the messages. At least, that's my theory based on observation.

[dunbarx]

Jacque.

If the mouseUp handler was in the card script, of course. We all do that sort of thing. Early on I asked the OP if the card script was something to investigate.

But the handler is in the button script. That means if the button is not there, the handler is not there.

Did I mention I do not believe in ghosts, but am quite certain I heard one?

Craig

[jacque]

I'm not sure how to explain this any better. Once the button is re-enabled, the backed-up messages start arriving at it.

Button is disabled, wait is initiated -> mouse events begin backing up in a queue
Wait period ends -> queued event messages start firing
Button is enabled immediately -> messages that would have bypassed the button now begin hitting it

Because the button is enabled within microseconds after the wait period ends, it is immediately available to receive the messages.

Maybe you are thinking that the target is set up at the moment the message is created. That doesn't appear to be the case. What it looks like is that a message is generated by the engine and waits in the queue until it is later fired. At the moment of firing, the engine determines the appropriate target, which is the topmost enabled object at the location of the mouse click.

Edit: this is based on observation. If that isn't how it should work then it's a bug, though maybe a long-standing one.

[dunbarx]

I guess I need guidance from Edinburgh.

1- User clicks on button. Button is disabled. Wait period starts.
2- While button is disabled, user clicks some more on the button.
3- Wait period ends.
4- Those *later* clicks, made on the *disabled* button, appear out of the queue.

It's that #4 that is disconcerting me. I will check HC when I get back to my office tomorrow.

Scotland?

Craig

Edit.

Jacque, if the button is disabled, why do the mouseUp messages not pass right through that button, all the way up ( ) and out the top ( ), discarded like any other unhandled, unrequited message? I would have no problem if the user clicked on an *enabled* control during the wait period. In other words, it isn't the fact that messages are generated during the wait time, it is that control-specific handlers are invoked from a control that ought to be invisible.

[dunbarx]

KaraSyrup.

Are you a pecan pie afficionodo?

Anyway, you have hit on a bit of LC esoterica that has me stumped. Keep up the good work.

Craig

[jacque]

Craig,

In the OP's handler, messages are resumed at the same time the button is re-enabled, effectively meaning that messages are going to an enabled object.

A rough analogy: Imagine you have a water spigot that drips at a regular rate into a bowl. You close the spigot and remove the bowl. The water builds up behind the stopper. You then open the spigot and immediately put the bowl back. The first drop or two may miss the bowl, but as soon as it's in place the remainder of the build-up goes into the bowl as usual.

Ditto the messages. What appears to be happening: messaages are not targeted at an object when they are created, their target appears to be determined at the time they fire. If the button is active when they fire, they hit it. This assumes messages are stored as mouse events with associated coordinates, unassociated with any particular object. Whatever is active at the coordinates when they fire receives the message.

The whole issue could probably be avoided by using "wait with messages" instead of just a blocking "wait" command. That would eliminate the queueing so that no backup messages would be around to hit the button after the wait. It would then behave as you expect. However, this could cause issues with other handlers, depending on the scripts.

Another way to eliminate the issue is to use the flag method which doesn't act on mouse events if the flag is set. That's more than some users want to do though, as it requires splitting out the behavior into separate handlers. But it's reliable and non-blocking.

If anyone who can read the source code cares to chime in, I too am curious to know what's really going on.

[jacque]

Another way to describe what I see is that messages are stored in the queue like this (hugely simplified):

mouseUp at 10,10
mouseUp at 12,10
mouseUp at 15,14
mouseUp at 9,8

When these eventually get fired off, whatever control is active, topmost and at those coordinates receives the mouseUps. I.e., messages are not control-specific. Or at least, not in this case. (Some messages do target specific objects, often in mobile apps.)

[dave.kilroy]

@Jacque I think you've just explained why an app I was working on a couple of years ago with 'fairly lengthy and wild' animations had me flummoxed trying to handle extra button clicks and keystrokes during animations. I DID have the various controls disabled and had to handle the "backed up water" (i.e. pent-up messages from your analogy) once they were re-enabled. If only I hadn't disabled them in the first place!

Thanks for the explanations - the behaviour in that app makes much more sense now

Kind regards

Dave