LiveCode Forums.

I Can confirm there are no ghosts involved , this is a lesser spotted Bug as it plain doesn't work as intended.
I ALWAYS assumed a disabled button means disabled - no events accepted , seems we were all mistaken. Also I noticed that although the"submit" button is hidden before the wait there is quite marked delay before it is hidden, it should be instantaneous because it is before the delay/wait. So somehow a wait (with or without messages) delays the preceding hide button command (more ghosts??).

The FIX
I renamed the button names from XYZ to more sane names so that the men in white coats didn't turn up and used a send in x seconds for the 3 second delay for the enable - that fixed the delay before hiding.
I then sent the disable "button pick" in a few ticks (almost instant) and that fixed the "ghost" click working on a disabled button.

btw this is on LC 6.7 so it must be an ongoing bug.

I can see how for most people it won't be a problem but young children and especially Autistic children will press buttons whether disabled or not.
Regards Lagi

After reading this thread a couple of times and some tests, I think these
two little words make the difference with wait and queued messages: WITHOUT WAITING!

Here:
...
disable btn "XYZ"
wait 5 secs
enable btn "XYZ"
...
The engine will collect ALL events, here CLICKS on button XYZ, and fire them after enabling
that button again, obviously the engine has nothing else to do during the wait.

Here:
...
disable btn "XYZ"
wait 5 secs WITH MESSAGES
enable btn "XYZ"
...
This does NOT happen, no messages are queued, since the engine has other things to do during the wait!

@Craig
Does this ease your mind as it eased mine?

er..

Klaus wrote:After reading this thread a couple of times and some tests, I think these
two little words make the difference with wait and queued messages:

WITH MESSAGES

that's what you said above, right Klausimausi?

Hi


I should have read the whole thread. I did use the with messages option and yes it fixed the problem with the "ghost" but I then noticed that the Submit button wasn't hiding straight away and "solved" that with the send in time method.

I then forgot about the original "fix" as I was distracted from real work (solving android upload problems hint hint!!!) But as I said the fact that I press on a button that should hide instantaneously but "waits" upto 2 seconds (with or without messages before it does is definitely a ghost.

By the way Jacque's post was was a very erudite exposition of the problem

Regards Lagi

Klausimausi?

Ahem.

Jacque:

This assumes messages are stored as mouse events with associated coordinates, unassociated with any particular object

Well, if that is the case, and since a naked "wait" queues messages, then I get it. Simple.

I just never knew that. I never heard of it. I know nothing about it. Anyone else know that it is not a control, a "target" one might venture, that receives first crack at, say, a "mouseUp" message, but rather a loc on the card window? And that this is immediately resolved into "OK,I see a click at "100,100". Any controls there? Yes? Well what do you know? Well then, why don't we queue this: Now to be fair, maybe this nonsense only occurs during a wait interval, and not "normally"?

Hmmmm?? Scotland?????

Craig

By the way, this coordinate-based clicking works the same if you hide the control instead of merely disabling it. I suppose that make sense, or at least is consistent...

Craig

Edit.

By the way again, this is just the sort of thing that Jacque seems to know that nobody else does.

SparkOut wrote:er..

Klaus wrote:After reading this thread a couple of times and some tests, I think these
two little words make the difference with wait and queued messages:

WITH MESSAGES

that's what you said above, right Klausimausi?

Yes, sorry for the "WITHOUT WAITING", of course I meant "WITH MESSAGES"!

dunbarx wrote:By the way again, this is just the sort of thing that Jacque seems to know that nobody else does.

I don't actually, truly, for-sure know it, I deduced it because it seems to fit all the evidence. But I could easily be wrong, and it would be interesting if someone could verify it.

I'm also not sure if the click queue is always location-based or just when it gets piled up in a backlog. I do know that some messages are always sent to specific objects, like messages about mobile controls which are sent to the script that created them. But that's because it's in the dictionary.

I've had another, probably more accurate, deduction. Let's say the queue doesn't store coordinates, it does store the target instead. So you have a backup that looks like this:

mouseUp to btn 12
mouseUp to btn 12
mouseUp to btn 12

They start firing when the wait completes. At the same time, the button is re-enabled. That means the mouseUps will trigger as they are sent simply because they are going to a now-enabled button. (I think this is where I started when I first replied but I got sidetracked.)

Jacque.

You have always been so keen on the sequence of events, and the state of the button along that timeline.

The question is why these messages are trapped at all, not their timing. I say that when one clicks on a disabled or a hidden (!) button, no target should be in the line of fire, and none registered. Period. And if that is so, then the message should be discarded on the ash heap of history, just like the Soviet Union, or any other untrapped message.

There should be no target available to trap it. If I overlie a handful of buttons, all with their own mouseUp handler, and hide them all, may I assume that the highest layer hidden button will receive the message?

Really?

Your coordinate idea, ostensibly valid only during a wait interval, at least can be understood and managed, and might even be mangled into a feature, however unintuitive. I thought LC was supposed to be intuitive.

I am thinking of submitting this to QCC as a bug, just to see what the team says. The silence from this thread is deafening.

Craig

I don't think it's a bug. At the time the queue unwinds, the button is active.

Suppose you send mouseUp to the button in 10 seconds, and during that 10 seconds you enable the button. Would you expect it to fire?

... (Happy new year!) ...

Hi Jacque

If I will be sending messages to a disabled button I would rethink my whole interface.

Probably have the button call a procedure that checks if the button is disabled
And is called by the button but any send to messages become calls to the procedure

Ps. Oviduct has mentioned about the anomaly of the hide button taking time to hide even though
The wait statement is after the hide statement

Lagi

Edit: Oviduct should be Nobody it was "translated" by predictive text on an Iphone while half asleep. Sorry for the smelling pistakes

Well I did hide some buttons. Three of them, btns 2, 3 and 4. Each had a short mouseUp handler that returned their individual names. I overlaid them on top of each other and then hid them. I made another button and put this into its script: Click on the working button. The three vanish. Click on the spot they used to occupy. Wait. The handler in the topmost hidden button fires.

If not click coordinates, how do it know?

Craig

Jacque.

Suppose you send mouseUp to the button in 10 seconds, and during that 10 seconds you enable the button. Would you expect it to fire?

I see what you are getting at, but yes, I would expect it to fire. This is "Live" Code, after all. If I send a message out into the cold cruel world to a button that currently is disabled or hidden, who cares? When the timing interval has elapsed, and the button has in the meantime appeared and/or been enabled, then why wouldn't LC send that message to that unremarkable, currently perfectly accessible button? Sending a message to a hidden or disabled button is something I do all the time, and I do not have to show it to expect it to work.

That is entirely different than *clicking* on a button that by all rights ought not to be available at all. Clicking. Not available.

In other words, I see this as entirely different from *sending* a message to a control, regardless of that controls current properties. Clicking on it is a UI action, not an "internal" action.Perhaps that is the crux of my point. Disabling or hiding ought to have a profound effect on the user interface. If a control is hidden or disabled, it should be hidden or disabled.

Craig