Inappropriate Interface Behaviour during mouseDown

[Igor de Oliveira Couto]

Dear Revolution Folks,

Thank you for your feedback to:

>> If a user presses down a button,
>> and then moves away, the button should not remain highlighted once the
>> cursor moves beyond the button's boundaries.


 From Ken Ray:

> In my checking, it doesn't. If you make a standard button (so that it
> includes the autohilite property), if you mouseDown on the button it is
> depressed. If you then move the mouse outside the boundaries of the 
> button,
> it "pops out" again. Are you not getting this behavior?
>

 From Scott Raney:

> What you're talking about is called "tracking" in GUI jargon.  Buttons
> with automatic behavior do tracking automatically, and you can even
> have them change icons automatically (see armedIcon, hilitedIcon,
> etc.).  If the automatic behavior doesn't do what you need, then
> you'll have to handle the tracking yourself using the mouseMove
> message (e.g, "if x, y is within the rect of me then ...")

Indeed, I do get this behaviour as well. It DOES work for buttons.
However, if you try to setup a 'custom button' using image objects 
(which is what I am working on, as these buttons have to have irregular 
clickable areas), and try to implement this behaviour by scripting 
mouse events (I am changing the image's alpha and imageData on the 
appropriate mouseUp/Down/Enter/Leave/Release messages), then it does 
NOT behave as expected.

 From Scott Raney:

> Secondly, when a mouse button is pressed down in a control, that
> control gets a "grab" on the mouse such that all mouse messages go to
> that object until the mouse button is released.  This is a core
> behavior of all GUI systems, and is why all mouseMove messages go to
> that control and why mouseEnter/mouseLeave messages are not sent: From
> the perspective of that control it still "owns" the mouse and so the
> mouse can never "leave".  This is a feature, not a bug.

I must admit, in my limited view, I fail to see how this implementation 
can be seen as a 'feature'. I fail to see why a control needs to 'own' 
the mouse until it is released. I (perhaps foolishly) thought that the 
appropriate message should be passed to whatever control happens to be 
underneath the mouse at a certain point in time, NOT to the last 
control where the mouse button was held down... If I put 3 buttons next 
to each other, press the mouse down on the first, and while still 
holding it down, move over the other 2 buttons, should they highlight? 
If so, then they MUST be able to receive messages as well. Otherwise, 
the 'owner' of the button (which is the first button) would be the only 
one receiving the messages, and my other 2 buttons would not highlight, 
even though now my mouse is pressed firmly down over one of them...

It seems to me that this implementation is also quite inefficient (it 
requires that a 'mouseRelease' message be implemented as well, while in 
other systems that message is unnecessary), and it is probably the 
reason why we've observed the unexpected behaviour of controls on 
hiding/showing objects from under the mouse (I can see now that the 
hidden object still 'owns' the mouse).

Hmmm, if this was implemented this way, I know that there must be 
situations where this kind of behaviour might be seen as useful, 
however I must confess I can't think of any. I would rather have the 
engine behave as expected, and be able to work with one less message. 
In theory, I should have been able to implement my wanted behaviour 
simply by hiding/showing the appropriate images from under the cursor 
(on mouseEnter/Leave/Down). If you have been following the discussion 
on this list (the topic was "Showing/Hiding images on mouseLeave...") 
you will see that this is currently not possible.

In regards to using 'mouseMove' to track mouse position relative to the 
'owner' control: considering that Revolution's built-in 'button' 
control DOES do the tracking as expected, and that the same tracking 
seemed to be currently impossible to implement via script on other 
controls (ie, image controls), I assumed that the error was in how the 
script language (and its handling of messages) was implemented. As a 
novice to Revolution, I surely would not have thought of using 
'mouseMove', as this seems to be a fairly low-level way of implementing 
simple button functionality: ie, why should I have to continuously work 
out if the mouse is still in the rect of the image, if there is a 
'mouseLeave' message that should be telling me just that? Also, using 
mouseMove makes it much harder to track irregularly shaped images (more 
complex scripts that check the alphaData on a certain pixel are 
needed), and it does not cover situations where the image is set to be 
'hidden' via script from under the mouse (which SHOULD trigger a 
'mouseLeave' message).

Yes, it might well be that I am not being able to see some incredibly 
useful functionality that has been given to us by the current 
implementation of the mouse messaging scheme in Revolution - but from 
this newbie's perspective, it does indeed feel like a 'bug'... not a 
'feature'...

Kind Regards,
--
Igor de Oliveira Couto
----------------------------------
info at pixelmedia.com.au
----------------------------------