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:
Indeed, I do get this behaviour as well. It DOES work for buttons.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 ...")
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:
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...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.
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
----------------------------------
[EMAIL PROTECTED]
----------------------------------
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
