pixelbird at interisland.net
Sun Nov 16 16:23:17 CST 2003
> 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
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.
More information about the use-livecode