mouseStillDown instability

[dunbarx]

I hope someone else will see this.

Make a new mainstack, place this in the stack script:

Code: Select all

on mouseStillDown
   put random(999)
   wait 1
end mouseStillDown

Never fires. Now if I place this in the card script (or a control), it always fires, and then, maybe, after fooling around for a while, commenting out the card handler and uncommenting and so forth, I can coax the stack script handler to work. But not always...

Craig Newman

EDIT: The message watcher does not register that this message is sent at all when the mouse is held down on the card area and only the stack script contains the handler.

[FourthWorld]

From the Dictionary entry for mouseStillDown:

Note: If there is no mouseStillDown handler in the target object's script, no mouseStillDown message is sent, even if there is a mouseStillDown handler in an object that's further along the message path.

There are only a handful of messages handled this way (idle and mouseWithin come to mind; there may be one or two others), and while it's quite a deviation from traditional xTalk it was done to encourage using newer messages that are usually more efficient.

With idle, for example, you can usually do what you need with much finer control and less CPU overhead by using timers instead.

With mouseStillDown, it requires the engine to poll the OS for the current mouse state, and this continuous polling is usually only meaningful when the mouse position changes - either the mouse is down within the target control, or it has moved off of it. While the script-driven polling seemed to work well enough under Mac Classic in HyperCard, modern systems provide a mouseMove message to note such changes, with the polling happening at the device/OS level where it's much more efficient.

So a quick solution would be to add a mouseStillDown handler in the target control, perhaps passing it if you want to handle that at the stack level.

But depending on why you're using mouseStillDown, it may be less load on the CPU to use mouseMove instead, taking action when the mouse enters or leaves the target control. It would require also writing mouseDown, mouseUp, and mouseRelease handlers to complete the tracking, but the small cost of a few extra minutes' scripting usually pays off with a much lower load on the CPU.

There's a discussion about this in the RQCC in response to a request I'd submitted to revise how mouseStillDown works in LiveCode - while it's been marked "Closed, not fixable", it may be helpful for understanding why it's implemented as it is:
http://quality.runrev.com/show_bug.cgi?id=1832

[dunbarx]

Richard.

Thanks for the reply. I am with you on the dictionary note. But then why does it work at the card level? This is where I got tripped up originally, trying to help in another thread. I guess a card is considered a "target object", but not a stack? OK, as long as I know...

Craig

[FourthWorld]

At first I thought this was an inconsistency, but after thinking about it a bit more it makes sense because the card is the target object.

Note that when you have a mouseStillDown handler in a card script, it doesn't trigger when you hold the mouse down on any control on the card, but only when the mouse is down on the card itself.

[dunbarx]

Richard.

Note that when you have a mouseStillDown handler in a card script, it doesn't trigger when you hold the mouse down on any control on the card, but only when the mouse is down on the card itself.

I didn't just fall off the onion truck, you know.

Craig

[Klaus]

[FourthWorld]

Richard.

Note that when you have a mouseStillDown handler in a card script, it doesn't trigger when you hold the mouse down on any control on the card, but only when the mouse is down on the card itself.

I didn't just fall off the onion truck, you know.

I must have, because after you asked "But then why does it work at the card level?" until I thought about it a bit longer I was considering filing a bug report against the current behavior.

[dunbarx]

Richard.

I was th...

Wait a minute, what is Klaus laughing at??? This is a southern U.S. saying.

Anyway, like you, the more I think about it, the card is indeed an object, and the stack really is not; these two are quite different. The card is an object that fills the window, but the window (stack) itself is more a manifestation of an underlying file construct.

So it makes sense that you can click on the card, but maybe makes no sense that you can click on the "stack". In this way, the card is definitely a viable target, but not the stack. And even though you can send a message to either, this does not automatically place the stack in the same class as a button or card.

I feel better...

Craig

[jacque]

And to make it even more confusing, a card responds like an object but it isn't a control. Referring to it as a control throws a script error.

Ain't life wonderful?