[email protected] 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 | [email protected]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
