dead click functions
DunbarX at aol.com
DunbarX at aol.com
Sun Jun 7 22:39:05 CDT 2009
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.
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.
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"
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.
In a message dated 6/6/09 10:16:00 PM, jacque at hyperactivesw.com writes:
> DunbarX at aol.com wrote:
> > One button, one field with text in it. I click the button and then click
> > the field.
> > Button script:
> > on mouseUp
> > set cursor to cross
> > wait until the mouseClick
> > put the clicktext
> > end mouseUp
> > In HC, one gets data from this and similar text/chunk
> > (clickText,clickChunk) functions, even in unlocked fields.
> > In Rev, one does not; empty is returned. The functions all work if the
> > handler is in the field script though. Something I am missing in the way
> > operate in Rev?
> > However, the clickLoc (and similar types like clickV and clickH) works
> > the button. Why?
> The mouseclick function is ephemeral and not always reliable. In HC, the
> engine kept a queue of events and always knew when three events happened
> sequentially (mouse down, still down, up). MetaCard used to do this
> early on and the mouseclick worked about the same way as HC. But
> eventually this got in the way of other mouse messages as the language
> matured, and Scott Raney started a brief discussion on the MC list about
> how to resolve the problem. The upshoot was that the old behavior was
> dropped and instead, the engine only checks for a mouseclick (and other
> mouse states) at the exact moment the script asks for it. If the
> necessary events aren't present in the queue at that precise moment,
> nothing is returned.
> This is also why checking for a mouseclick inside a repeat loop is a bad
> idea, especially in long loops. There's a chance that the loop won't
> notice a mouseclick has happened.
> There are better ways in Rev to get the same info that the mouse
> messages used to get in HC. In this case, a selectionChanged message
> would probably do it. On selectionchanged, check the selectedtext, or
> the selectedChunk, or the clicktext, or whatever you need to know.
> My web page on mouse polling explains some related concepts:
> Jacqueline Landman Gay | jacque at hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
We found the real ‘Hotel California’ and the ‘Seinfeld’
diner. What will you find? Explore WhereItsAt.com.
More information about the use-livecode