Inappropriate Interface Behaviour during mouseDown

[Igor de Oliveira Couto]

Dear Scott,

Thank you for your comments.

On Tuesday, November 19, 2002, at 08:58  AM, Scott Raney wrote:

>> 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
> ;-)
>

*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!

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.

>> , 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.

Actually, that would already be a great improvement! That would be 
wonderful, and make things incredibly more intuitive!

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
----------------------------------
info at pixelmedia.com.au
----------------------------------