|
Writing Mouse Handlers
What this page is about
If you develop mouse handlers in your app, you may wish to give certain
of them the following form to be consistent with the form of the WFS
behaviors. Some of the WFS behaviors contain mouse handlers, and some
of the mouse handlers do not execute unconditionally but according to
certain conditions described below.
Mouse Handlers for Window Elements
Form for mouseEnter, mouseUp, and mouseLeave
If you attach behaviors that contain mouse handlers to Window Elements,
you may wish to give the mouseEnter, mouseUp, and mouseLeave handlers
the following form. Whether you should will of course depend on your
intentions and the nature of the functionality you are implementing.
However, I thought it best to provide these notes concerning the standard
form of WFS behaviors. A tricky issue that I have sweated to make as
simple as possible.
When WFS behaviors have mouse event handlers that are not mentioned
below, the event handlers execute unconditionally.
property spriteNum
on mouseEnter me
if the mouseDown
= FALSE then
--PUT YOUR CODE HERE
end
if
end mouseenter
on mouseUp me
if the clickOn
= spriteNum then
--PUT YOUR CODE HERE
end
if
end mouseUp
on mouseLeave me
if the mouseDown
= FALSE then
--PUT YOUR CODE HERE
end
if
end mouseleave
mouseEnter notes
In windows, when you mouse enter an element, you do not normally want
the mouseEnter behavior to be triggered unless the mouse is up. For
instance, if you are dragging something around the window and you happen
to mouse enter an element that has a mouseEnter behavior attached to
it, you normally do not want the mouseEnter behavior to be triggered.
There will be exceptions to this, but the "Close My Window",
"Open a Window", "Close a Window", and "Rollover"
behaviors contain mouseEnter handlers that do not execute if the mouse
is down when you enter sprites that have these behaviors.
Neither does the "Cursor Control" behavior change the cursor
if you enter a sprite that has the "Cursor Control" behavior
while the mouse is down.
mouseUp notes
Suppose window element B has a mouseUp handler in some behavior attached
to it. You mouse down on element A, keep the mouse down, drag to element
B, and release the mouse. Normally you would not want the mouseUp behavior
of element B to execute. Unless you were dragging element A onto element
B. In which case the mouseUp handler of element B would not execute
if A also contained a mouseUp handler. So in either case, we normally
do not want the mouseUp of B to execute when it was not the last item
clicked.
There will be exceptions to this rule of course. But the "Close
My Window", "Open a Window", and "Close a Window"
behaviors have mouseUp handlers that do not execute if the sprites to
which they are attached were not the last sprites clicked.
The "Cursor Control" behavior does, however, execute unconditionally
on mouseUp. This is intentional.
mouseLeave notes
The argument concerning why I have chosen the form I have for the mouseLeave
handler is the same as the argument concerning the form I've chosen
for mouseEnter.
There will be exceptions to this rule, of course. But the "Open
a Window" behavior contains a mouseLeave handler that does not
execute if the mouse is down when you leave the sprite.
The "Rollover", "5: Close My Window" and "Close
A Window" behaviors also contain a mouseLeave handler, but the
window is closed regardless of whether the mouse is down or not. This
avoids the case where the user enters, mouses down, leaves the sprite,
and thus leaves the window open. I thought you normally would want the
window to be closed in this case.
The "Cursor Control" behavior does not execute if you leave
a sprite to which it is attached when the mouse is down.
Mouse Handlers for Menu Elements
Form for Menu Element Mouse Handlers
The "Menu Verb" behavior is the central behavior concerning
mouse events and menus. The "Menu Verb" behavior contains
mouseEnter, mouseDown, mouseUp, mouseLeave, and rightMouseDown handlers,
and these execute unconditionally. Consequently, if you write and attach
mouse handlers to menu items, let the mouse events execute unconditionally
unless this is contrary to your intentions. That is the standard, in
any case.
Notes on Rationale for the Form
If you play with menus in standard applications, you see that they
behave a bit different from window elements. For instance, if you click
to open a menu, keep the mouse down, drag to a menu item, and release
the mouse, the selection is made. Compare this with what happens when
you mouse down on a window element button, keep the mouse down, drag
to a different button, and release the mouse. The button does not behave
as though it has been clicked, though the triggering event is mouseUp.
Why are window and menu elements different this way? Because menus
are built for speed of selection; they let you be a bit inconsistent
yet you get what you want. Whereas window elements make sure you can
cancel an operation if you mousedown and then change your mind.
In keeping with an attempt to let WFS menus behave like standard menus,
if so configured, the standard mouse handlers are a bit different from
the standard window mouse handlers. The "Menu Verb" behavior
contains mouseEnter, mouseDown, mouseUp, mouseLeave, and rightMouseDown
handlers, and these execute unconditionally.
Consequently, they are slightly inconsistent with the "Cursor
Control" behavior. But only slightly so. The mouseEnter and mouseLeave
handlers of the "Cursor Control" behavior do not execute if
the mouse is down when the events are triggered, whereas these events
will be triggered if the mouse is down in the "Menu Verb"
handler.
|
Writing
Mouse Handlers
1: prepareMovie
2: Window Manager
3: Window Manager
4: Win/Menu Element
5: Close My Window
6b: Handle
Menu Manager
Menu Manager
Menu Verb
Menu item highlight