dead click functions
J. Landman Gay
jacque at hyperactivesw.com
Mon Jun 8 11:53:55 EDT 2009
DunbarX at aol.com wrote:
> The goal is to be able to get info about text in an object, initiated by a
> handler in a different object, by pinpointing that text with the mouse.
>
> The workaround, of course, is simple:
>
> set cursor to cross
> wait until the mouseClick
> click at the clickLoc
> put the clickChar -- or any other chunk-like click function
>
> So I will add a "newClickChar" (and newClickText and newClickChunk...)
> function to my toolbox, and move on.
>
> Does anyone think the unique properties of this function ought to be
> brought to the attention of Edinburg, so it does NOT change? So that the very
> difference itself is examined? Maybe not; I will be pissed if the clickLoc joins
> the ranks of its poorer cousins.
The clickloc won't change, and the mouseclick behavior was changed long
before Runtime acquired the engine and hasn't been altered since. But
because there are more efficient ways to do what you want, it may not be
much of an issue most of the time. Here's one way to do it:
on mouseUp -- in the button
send "checkChunk" to me in 1
end mouseUp
on checkChunk
if the mouse is down then
put the clickchar -- or whatever
else
send "checkChunk" to me in 1
end if
end checkChunk
This method works for both locked and unlocked fields, allows time for
the engine to update its message queue, doesn't require a "wait" or an
artificial click, provides time slices for background processes, and is
technically a more efficient way to do it. Of course, I'm also a firm
believer that whatever works for you is okay. :)
Wait statements and repeat loops are blocking, so it's good to avoid
them when possible. There are always times where you can't, but often
there are other ways to accomplish things.
--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode
mailing list