[email protected] wrote:
Jacques:
Well, OK, but then why do the "loc-like" functions always seem to work? And
why then do the "text-like" functions always work within the object itself?
If, as you say, the engine only checks at the exact moment the script asks
for it, then I don't get it. The engine, at mouseUp, knows at least two
things, that the mouse came up, and the cursor's loc where it did so. It must
hold that data for at least a little while, because I invoke the function
later on, down the lines, so to speak. I sort of understand why a repeat loop
might "miss" the event, but a "wait until the mouseClick", involed remotely
from another handler, ought to be as "immediate" as a call within a handler
seems to be.
Now you're asking me things that veer off into the great unknown. :) But
to my simple user brain, I think it must be something like this:
A "mouseclick" is actually a series of several messages: mouseup,
mousestilldown (3 of them, I think), and a mouseup. If all these aren't
in order in the message queue, you don't have a mouseclick.
So you have a button that executes the handler on mouseup, and then you
move the mouse to the field and click again. The messages that are sent
are something like this:
mousemove -- in the button, several of them
mouseleave -- in the button
mousemove -- going to the field, lots of these (and by now the handler
has probably already finished)
mouseEnter -- into the field
mousedown -- on the field
mouseStilldown -- in the field
mouseUp -- in the field
There are lots of intervening messages between the mouseup in the button
and the "mouseclick" events in the field. The button script has already
finished, probably before the cursor ever enters the field. It misses
the "mouseclick" check. When you call the same handler from inside the
field itself, there are no mousemoves, no mouseleaves, etc. The series
of messages that constitute a "mouseclick" are more likely to be caught.
I think. Maybe someone else knows.
On the other hand, the engine does always know all the "loc" info
because that isn't stored as a series of events, it's a single event.
Off the top of my head, the only "event" I can think of that isn't
really a single event is the mouseclick function.
The selectionChanged message seems like a powerful tool, but it is not
helpful to me when I want to get information on a piece of text I click on in,
say, a locked field. There is no selection made and certainly none changed,
just an event over a bit of text. The whole beauty of the xtalk world is that
the language indulges the logic of the programmer.
If the field is locked, you can use a mouseup handler in the field to
get the clicktext or whatever else you need. Or if you want a remote
handler that isn't located in the field, the "send" structure described
in my web page comes in handy.
I have a bunch of ideas that I will check tomorrow. But they all involve
some sort of workaround using what seems to be the reliable "loc-like"
functions.
All the fuctions are reliable, but the mouseclick is implemented
somewhat differently than in HC. But as far as I know, that's the only
one you may need to handle differently. Any kind of polling is
discouraged though (and waiting till the mouseclick is polling) because
it ties up the CPU. It leaves no time for other processes.
But am I the only one whe ever wanted to pinpoint text, remotely, for one
reason or other by clicking on it? These functions seem much diminished, and
certainly less indulgent, if they can only be used within a mouseUp handler
that subsequently calls the function.
No, it's a common task. I'll see if I can dig up an example script
tomorrow if someone else doesn't chime in first.
--
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
