messages to buttons when the mouse is already down

[Ken Norris (dialup)]

on 1/21/02 10:37 PM, David Vaughan at drvaughan55 at mac.com wrote:
 
> Er...no it isn't Ken. I tested it.
----------
Well, you're right, but it's much worse than that. See my apolgetic. The
script I wrote was intended to not only hilite on entry, but also execute
whatever the button is supposed to do when clicked, all in one handler. It
didn't work, as far as it went, because I forgot to put in the last repeat.

Howsomever...Michael was asking for the buttons to hilite with the mouse
button already down, so my thing failed from the get-go.

If the buttons are a grid, all the same size and equally spaced, we can
determine which one the cursor is in because we already know those numbers,
and the formula, something like:

(round((item 1 of mouseLoc)/100)+1) & comma & (round((item 2 of
mouseLoc)/100)+1)

for, uh, 50 pixel square buttons, I think, should get a match, once you've
initialized the grid. I haven't looked this over, but you can modify it.
Solving this equation will be much faster than looking through an entire
array of button rects, but it does depend on the sameness of a matrix.

Another non-idle-handler solution might be to speed up the mouseMove/button
rect search by initializing a string with item-delimited chunks to hold all
the button rects and, say, their ID numbers. I think a well written script
could chew up a string that is in memory and spit out a match faster than
searching the buttons themselves.


Just an idea...

Best regards,
Ken N.