mouseDown cripples menuPick

[dunbarx]

Not sure if this is expected behavior. It made my life miserable for a bit.

On a new card place a pulldown menu button. In the button script:

Code: Select all

on menuPick pItemName
   set the label of me to pItemName
end menuPick

No problem, and the default three choices allows one to see the button in action.

Now, in the card script:

Code: Select all

on mouseDown
   exit to top
end mouseDown

Now the menu button does not work.

So one cannot trap "mouseDown" at the card level and expect a menu button script to fire, even though that script is local to the button . OK, I guess, as long as one knows about it. I had such a mouseDown handler that validated certain target controls, not allowing that message to pass through the ones of interest to me. It crippled new menu-style buttons.

Now I know.

Is this OK with everyone?

Craig

[bogs]

Hm. I thought the way the message path worked, what your describing couldn't happen. Have I got the message path wrong again?

[dunbarx]

Bogs.

I don't think it can be so much a message path issue. The card is above (don't, Jacque) the controls it owns, and I just don't have the feeling that this is broken here.

I think, assuming it is not just an outrageous bug, that the "mouseDown" message is somehow internally intimately tied to the whole process of sending a "menuPick" message. That is, if one shuts off the first, so does one shut off the second.

Unless others think this is either old hat or an indispensable feature, I consider it a bug.

Craig

[rkriesel]

Code: Select all

on mouseDown
   exit to top
end mouseDown

Now the menu button does not work.
<snip>
Is this OK with everyone?

A system event handler that does not pass risks failure.

mouseDown would happen before menuPick. Why should something happen after exit to top?

-- Dick

[bogs]

I don't think it can be so much a message path issue. The card is above (don't, Jacque) the controls it owns, and I just don't have the feeling that this is broken here.

Well, like I said, maybe I just (still) don't understand the whole path thingie but from your description, it sure sounds like a path thingie to me. Just for reference, the path as laid out in Lc's lessons.

The problem your stating as my understanding of it goes in relation to the path :

1. Button (object) on card gets input event to run menuPick script in button
2. Card also has mouseDown script that exits, but is farther down the path

Now if you had said you had the exit mouseDown in the button, that would be one thing, but you don't. Since I assume your clicking on the button, and the menuPick script is in it, and the button is on the card, that in my understanding would get the priority in the path.

It would seem (to me) silly to require you to put in a mouseDown or mouseUp message to trigger the menuPick of a menu button, which is after all its primary function in life, in an object (card) farther down the message path.

[dunbarx]

mouseDown would happen before menuPick. Why should something happen after exit to top?

You make a point here, and maybe it is pertinent.

But the menuPick handler lives in its own space in its own handler, and just because I exit the mouseDown handler all the way back to nothingness should not preclude another message from being sent from another, separate process.

If what you said was correct, then trapping and burying "mouseDown" ought not to allow the menu button to "fire", that is, the menuItems ought not to appear at all. But they do, so "mouseDown" does not seem to affect that action. And if the menu button is enabled sufficiently to display the menuItems, I assert it is independent enough to allow the menuPick message to be sent.

It does not. "MenuPick" is not sent at all.

Craig

[dunbarx]

Bogs.

Well, like I said, maybe I just (still) don't understand the whole path thingie

Of course you do. But I want you to tell Jacque that messages go "up" the hierarchy and not "down". She will not listen to me.

Craig

[bogs]

I want you to tell Jacque...

You want what?!


On a more serious note, I'm glad I don't (still) completely misunderstand how it is supposed to work

[jacque]

I have given up on directional references. I now use "before" and "after". That accommodates any mental model. Personally I think of the path as a road from one location to another.

I just recently learned that mouseUp is an artificially generated message, since the OS doesn't notify about it. Perhaps blocking mouseDown affects that. I'd assume also that menuPick is artificially generated after a mouseDown when the engine determines the target is a menu object.

[dunbarx]

Jacque.

If I change the mouseDown handler to:

Code: Select all

on mouseDown
   exit mouseDown
   --not "exit to top"
end mouseDown

The "menuPick message is sent.

But are we then both still right, that mouseDown informs menuPick? I am having trouble wrapping my head around the difference, but of course, I do not know what goes on under the hood.

"Before" and "after", eh? We will have to redraw the hierarchy horizontally. But then can we still call it a "hierarchy"?

Craig

[FourthWorld]

menuPick is sent after the mouse is up in a menu. The mouse can only come up, of course, after it has been down. If a mouseDown handler bypasses normal event handling with "exit to top", subsequent messages dependent on that message do not happen.

[SparkOut]

jacque is right (before/along a road), but she was also right before (down/in). But turtles are most right (swimming/floating downriver).

[dunbarx]

Richard wrote:

If a mouseDown handler bypasses normal event handling with "exit to top", subsequent messages dependent on that message do not happen.

As surmised, though only broadly; menuPick "depends" on mouseDown.

But I still am trying to grok the difference between simply exiting a mouseDown handler and exiting all the way to the engine. Exiting the mouseDown handler obviously leaves some memory of the mouseDown event in the engine, whereas exiting to top does not.

There has to be something "queued", or set up internally.

"MouseUp" does not fire at all in a menu Button, and "menuPick" therefore is not dependent on mouseUp. It ought to be, though.

Craig

[jacque]

But I still am trying to grok the difference between simply exiting a mouseDown handler and exiting all the way to the engine.

Exiting a handler returns it to the queue where it continues along the message path. Exiting to top specifically exits the message path entirely, effectively killing the message. Exit to top is what we used to call "exit to HyperCard".

[bogs]

@Jacque-
Hm, I think I almost understand that. I'm not sure I agree with it being that way, but it isn't like I'd be changing it either.

But turtles are most right (swimming/floating downriver).

...but not if I'm swimming and they are snappers