How to hide an option menu when no selection

[dunbarx]

Michael.

I told you this would be fun.

Craig

[jacque]

Interesting. It sounds like a side effect of the escapekey message:

Handle the escapeKey message if you want to perform some action when the user presses Escape.

The message is sent to the active (focused) control, or to the current card if no control is focused.

So maybe an escapekey handler is all that's needed.

[MichaelBluejay]

Read my first post: "on escapekey isn't sent when the menu is dropped."

[dunbarx]

Correct. The escapeKey message is not sent. But the keysDown function knows when the escapeKey is pressed, and that can be used to the same effect.

Craig

[MichaelBluejay]

I doubt it, given that, as I mentioned, rawKeysDown doesn't fire either when the menu is dropped. But anyway, since you solved the Escape problem long ago with on mouseRelease, this is all moot.

[dunbarx]

Michael.

I doubt it, given that, as I mentioned, rawKeysDown doesn't fire either when the menu is dropped.

Hmmm.

Just to be clear, in an open optionMenu, "mouseRelease" is sent. You're welcome.

It is sent for the reasons discussed above, and possibly those reasons are even true. And since a message of any kind is, thankfully, sent in such a condition, it is possible to exploit the "keysDown" function to do what you wanted.

Craig

[MichaelBluejay]

Just to be clear, in an open optionMenu, "mouseRelease" is sent. You're welcome.

Yeah, I said that in the post you just replied to.

[dunbarx]

Still trying to be clear. It may matter to others trying to learn from this thread, and the distinction is subtle.

What do you doubt?

True, we found a message sent from an open menuOption. That in itself was a surprise. But the "keysDown" function is not at all the "rawKeysDown" message. Is that where we are conflating two very different LC issues?

A function cannot be invoked outside of a running handler. It was finding a way to get a handler running at all from that control in that state that was something new we all learned.

I agree we are essentially done here. I just wanted to tie up all the loose endings.

Craig

[MichaelBluejay]

The proper function names are keyDown and rawKeyDown, not keysDown and rawKeysDown.

rawKeyDown does not fire when the option menu is open and the Escape key is pressed.

Code: Select all

--in both option menu script and stack script
on rawKeyDown
   answer "fired"
end rawKeyDown

[dunbarx]

Michael.

Please go to the dictionary and look up "keysDown".

You will find it a very useful function.

The items you mentioned above are MESSAGES. There is a profound difference between these concepts. You have mixed them up before.

Craig

[dunbarx]

Michael, again.

You must have misread my earlier post, the one you thanked me for, if you all along thought I was talking about any kind of key-Like message. Go back to that one and reread carefully.

Craig

[MichaelBluejay]

Craig,

I think we're talking past each other. I know that we can see the Escape key being pressed when the menu is open by trapping the on mouserelease handler and putting if the keysDown = 65307... into it. I commended you on that idea long ago (10/16 9:14am msg) and I added it to the first post on 10/16 as a solution.

[dunbarx]

The proper function names are keyDown and rawKeyDown, not keysDown and rawKeysDown.

rawKeyDown does not fire when the option menu is open and the Escape key is pressed.

As long as we understand that "keyDown" and "rawkeyDown" are messages, not functions.
The "keysDown" is a function.
There is no "rawKeysDown" at all.

Much of this discussion revolves around the fact that a function ("keysDown:") was effective when we exploited a rather anomalous behavior of a message ("mouseLeave"). The cool thing to me is that when one clicks at a loc under script control (opening an optionMenu) "mouseLeave" fires. One might think that the "virtual" cursor stays within the rect of the optiomenu when the "click at the loc..." command is run. It does not. Apparently it "goes" to the target control, but then "returns" to its initial loc.

Remember the "mouseLeave" message will not fire at all UNLESS the cursor leaves the target The virtual "click" makes LC think that the cursor has gone to the clickLoc, but then "returned" to its starting place, enabling the "mouseLeave" message to fire.This is something I need to test in other scenarios. But it actually seems right to me.

This is good stuff.

Craig

[dunbarx]

Anyone think this is a feature, a bug, expected behavior or just an anomaly?

The command "click at the loc of..." does indeed click at that loc. As read, though, it seems that the cursor ought to simply stay at the loc after the click. This is not the same as moving the cursor to that loc and manually clicking. If one does that, of course, the cursor remains in that location.

Doing this under script control has to actually "move" the cursor to the prescribed loc, and not just invoke some similarly functional internal engine action. We know this because a "mouseLeave" handler will fire if asked to. In order for that to happen, the cursor had to be actually on site, and had to actually leave that site. That is what "mouseLeave requires, and how "mouseLeave" works.

In other words, "click at the loc of..." actually physically moves the cursor wherever, clicks, and then actually returns it to its original loc.

So, feature, bug...?

Craig