Constraining 'grab'

[Ken Norris]

Hi Jan,

> Date: Sun, 16 Nov 2003 10:00:43 -0800 (PST)
> From: Jan Schenkel <janschenkel at yahoo.com>
> Subject: Re: Constraining 'grab'

> Actually, switching to a 'send in (time)' construction
> would be counter-productive : a mouseMove is only sent
> when the mouse actually moves around ; if you would
> check the location every 10 milliseconds or so, it
> would pose more strain on the engine, I think.
-----------
Not in the mouseMove, but just the setup in mouseDown. A one-time message.
But I think you're still right, it's really pointless except as exercise for
habit. However, for habit's sake, I don't think a one-time 20 millisecond
Send in the mouseDown message would affect the operation of the mouseMove
handler either.

Anyway, the 'engine' that makes it work is this little min/max one-liner in
the mouseMove handler:

set topLeft of me to \
   min(boxR - W,max(boxL,(x - CX))) & "," & min(boxB - H,max(boxT,(y - CY)))

...which is worth noting for anyone who wants to constrain an object to an
area. Before Scott noted this from the stack in his original post way last
year, I got an almost identical script from Colin Holgate on the HC list
sometime in late '01, which was implemented in a HC stack back then, the
difference being handled in a mouseMove (Rev) rather than a mouseStillDown
using the mouseLoc (HC).
-----------
> A parameter to constrain the grab would indeed be a
> nice addition to the language. Even nicer would be a
> way to simply constrain a control to a certain area.
----------
That's it. The 'grab' command is more efficient than a drag workaround, but,
by itself, with no other concurrently available constraints, parameters, or
message-handling ability, it seems rather useless, IMO.

Ken N.