LiveCode Forums.

Stam's way will work, there are lots of ways to do things in LC. To avoid needing a script local variable, I tried this:

In the button that selects the dropper tool: And in the card script: Since LC doesn't have a dropper cursor, I imported a custom image whose ID was 1005. I set the hotspot of the image to the appropriate spot in the image.

Since your graphics are a single color, getting the backgroundColor should be fine. The mouseColor will return the exact pixel color under the mouse, which is useful for images with multiple colors. Either way will work in this case.

If you will need different cursors for different tools, expand the card handler to account for each. This method assumes that none of the graphics have mouseUp handlers; if they do, pass the mouseUp in the graphic so the card handler will get it.

stam wrote: Mon May 02, 2022 2:56 am As a user, i would expect software to allow me to cancel an eyedropper tool by hitting the escape button.

I hadn't thought of that. So both our methods would need an escapeKey handler as well. Good thought.

-
It never ceases to amaze me what a continuing education these forums are.

Thanks Richmond - exactly that was is in my suggestion above.

But it’s hard to trigger on escapeKey if all the code is in a mouseUp handler…. Hence my approach of putting the code in the card script.

Well, yes, the problem is that unlike shiftKey and ctrlKey where you can do stuff like this:
doing that sort of thing with escapeKey does not work.

And, thinking about that, it might be a thought to badger LiveCode central to change the language so that
these types of things are possible:

arrowKey() is down

escapeKey() is down

functionKey() is down
-

richmond62 wrote: Mon May 02, 2022 11:10 am Well, yes, the problem is that unlike shiftKey and ctrlKey where you can do stuff like this:

Code: Select all

on mouseUp
if shiftKey() is down then
---- do something
else
---- do something else
end if
end mouseUp

doing that sort of thing with escapeKey does not work.

Quite... it would only be feasibly is you clicked the mouseButton while holding down the escapeKey so no good.

If one did want to keep all the code in the mouseUp handler, one way around this would be to have a global variable keep track if sampling or not.
In a card (or stack) script you could set this to false in the on escapeKey handler and check this in the mouseUp handler. Or you could remove the pending messages from the message queue in the escapeKey handler. But logistically for me it's simpler to separate the code into the card script...

I wonder what the rawKey code for the ESC key might be.

Richmond

65307 (escape)

Craig

One has to be careful when using a "mouseUp" handler in the same world as another handler that checks to see if the mouse is down. Or at least I do. The following never exits though it seems it ought to: Clicking the mouse to find the mouseColor also "restarts" the mouseUp handler itself. Lots of ways around that, of course.

Craig

Richmond

arrowKey() is down
escapeKey() is down
functionKey() is down

You are asking that LC create new functions where now we have messages. We do have some, of course, like "optionKey()".

Craig

You are asking that LC create new functions where now we have messages. We do have some, of course, like "optionKey()".

Whoops, have I committed a cardinal sin? I do hope so.

65307 (escape)

Hilarious: that was a rhetorical wonder.

I commit ordinal sins only.

I tried to emulate trapping the escape key in the midst of a handler doing its thing. Not easy. I could not make the "rawkeyDown" message fire in the middle of a running handler, and that was the only thing I could think of to try to insinuate into the flow.

Others may have more clever ideas, but without a function I don't see a way right now.

Craig

How about making "all the other stuff" happen
when one presses the ESC key?