Dear Scott, Thank you for your comments.
On Tuesday, November 19, 2002, at 08:58 AM, Scott Raney wrote:
*hehehehehehe* I'm affraid my experience does not go as far back as 1970! I must also admit that I am totally unfamiliar with 'Flash'... You give me far too much credit!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?It's an empirical question, which means you should try it yourself and see. In my experience on GUI systems (dating back to the Xerox Star) I've never seen one work this way for regular pushbuttons. Since you're apparently back in 1970, however, I can't rule out that you might find an early MIT or Xerox PARC prototype that works this way ;-)
My question was not empirical, though. I was NOT suggesting you open Mac windows and start clicking buttons to see whether they behave they way I described or not. My question was whether people in general think they SHOULD behave this way.
Apple spends a LOT of effort and money researching interface principles, but more than anyone, they know that their interface guidelines are not faultless. They might be award-winning, but not even Apple claims that they are perfect, and therefore, they continue on their research, and continue on improving and changing their guidelines.
My point is precisely that I want my interface to function a specific way, which is different to the way Revolution currently forces us to work. I might, indeed, want to create an application that behaves like a 1970's piece of software - or I might have other specific needs, for specific markets (such as young children, the disabled, or for specific testing purposes), which might require mouse responses to be handled in a different way.
The 'difference' between the way I would like my application to respond and the way it currently HAS to respond, is not enormous. However, a development tool, in my humble opinion, should be easy to use, but also give as much choice to the developer as possible. The reason why we like Revolution so much is because it gives us choice (compiling for many platforms) - and ease of use as well. I'm just calling your attention to an area where not enough CHOICE is being given. Also, unlike others who have followed the development of Revolution from the start, and know all the ins-and-outs of the software - and the rationale as to why things behave the way they do - I am a total stranger, and present a 'blank slate' to you. I will try to use things as they seem to me that they should be used. So, users like me, are also good test subjects for you to see whether Revolution is truly EASY and intuitive to use.
As a new Revolution user, and new to its scripting language, it appeared to me 'odd' that a 'mouseLeave' or 'mouseEnter' message should depend on the state of the mouse... It also appeared quite obvious that if mouseLeave/Enters were sent regardless of the mouse button status, then there wouldn't be a need for a 'mouseRelease' message, either. In my 'newbie' view, the mouseRelease message was just an extra complication that I'd rather not have to deal with.
Actually, that would already be a great improvement! That would be wonderful, and make things incredibly more intuitive!, 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).Right, at least while the button is down. Whether it should change when the button is up, however, is a different question and one we're currently researching. But even if we change this it wouldn't solve your problem.
Once again, I personally believe that the mouseEnter/Leave messages should be sent to the image being shown/hidden, regardless of the state of the mouse. I'll tell you why: one of my very first scripting experiences with Revolution was trying to setup an irregularly-shaped button, by using 3 image objects. Here is what I tried to do (and which did not work): I had 3 images ('idle', 'over' and 'down'), and I scripted them thus:
* For the 'idle' image:
on mouseEnter
hide me
show image "imgOver"
end mouseEnter
* For the 'over' image:
on mouseLeave
hide me
show image "imgIdle"
end mouseLeave
on mouseDown
hide me
show image "imgDown"
end mouseDown
* For the 'down' image:
on mouseUp
hide me
show image "imgOver"
end mouseUp
Because of the current restrictions with messages not being sent when images are hidden/shown, these did not work - or worked erratically. If you implemented mouseEnter/Leave as discussed, they would work.
Please note that this would indeed be a GREAT improvement: currently, to implement the same functionality as given by the scripts above, I had to follow suggestions given to me by the more experienced users in the list, and setup scripts that change the alphaData, imageData and size of a 'display' image, getting the image information from the 3 other hidden 'source' images ('idle', 'over' and 'down'). Not very intuitive AT ALL for a newbie.
Nevertheless, as noticed by you, this would still leave me with one problem: if the user moves away from the 'over' image while the mouse is down...
Right now, this event is not handled at all. I have to try and cater for it by scripting:
on mouseRelease
hide me
show image "imgIdle"
end mouseRelease
Which is how Revolution wants us to work. I would rather, however, use a 'mouseLeave' here, and forget about the 'mouseRelease' message altogether. I do not need to trap an event that tells me that 'the user pressed the mouse button on the image, moved away, and let go of the button outside the image'. While that is a GREAT shortcut for some tasks, all I need is 'the user has moved away'.
The absence of mouseEnter/Leave messages on hiding/showing objects hinted to the fact that this might be an area that could benefit from some improvement. That is why I pointed out what, for me, seemed like a cumbersome and LIMITING way of dealing with mouse messages. Users - and developers more than anyone else - appreciate choice.
Many thanks for your feedback, and
Kind Regards,
--
Igor de Oliveira Couto
----------------------------------
[EMAIL PROTECTED]
----------------------------------
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
