dead click functions

[J. Landman Gay]

DunbarX at aol.com 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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com