Option menu oddity?

[dunbarx]

Maybe everyone knows this but me.

Make a optionMenu button ("opt1") and a regular button. The default option menuItems will be the usual "Choice 1", "Choice 2" and "Choice 3"

In the script of the optionMenu:

Code: Select all

on menuPick pMenuItemName
   if pMenuItemName = "choice 2" then answer random(999)
end menuPick

In the script of the regular button:

Code: Select all

on mouseUp
  set the menuHistory  of btn "opt1" to "1" -- commenting this out makes the option not fire if "Choice 2" is already displayed
  set the menuHistory  of btn "opt1" to 2
end mouseup

Click on the regular button. Since the handler in the regular button sets the menuHistory of the option first to 1, and then to 2, the handler in the option fires. But if you click the button again, where the menuHistory in "opt1" is already 2, it will not fire. Of course, if you select "Choice 2" in the option directly, even if you already have "Choice 2" as the label, the handler fires.

But not remotely. Is this normal behavior? It tripped me up until I played around with it.

In any other menu-style button, where the label is not displayed, the menuPick handler will fire all the time, regardless of any previous remote selections.

Craig

[FourthWorld]

If I understand this correctly, this is a design decision for option controls to avoid triggering responses when the user isn't changing the selected option.

[dunbarx]

If I understand this correctly, this is a design decision for option controls to avoid triggering responses when the user isn't changing the selected option.

Ah.

I cannot think of a downside to allowing the reselection of an existing choice, but can easily imagine that restriction causing someone (me) to waste a bit of time trying to figure out why it was not working.

If it indeed had such an advantage, it would take all of one line in the menuPick handler to exit if the new selection matched the current label. That seems more prudent than denying the possibility at all.

Craig

[FourthWorld]

Maybe. It's been that way since MetaCard. I suppose you could take it up with Dr Raney.

To me it doesn't seem so bad. Semantically, option controls are primarily selectors, not actions triggers. While they can be scripted to trigger actions, such actions are usually limited to updating other UI elements in response to the changed selection; no change, no need to update.

There might also be recursion implications with some usage I'm not thinking of.

All I know is I've been using the platform since '97 and I can't recall this coming up before. That's not to suggest the design is necessarily optimal, just that it would seem to bother few.

[dunbarx]

All I know is I've been using the platform since '97 and I can't recall this coming up before

You didn't have me back in '97.

Craig

[FourthWorld]

All I know is I've been using the platform since '97 and I can't recall this coming up before

You didn't have me back in '97.

Craig

And we were a lesser community for the loss back then.

[dunbarx]

Aw.

But it just occurred to me that you can invoke an existing option from the control itself. You just cannot do it from afar. So there is a little wiggle room there, and by wiggle room, I mean inconsistency.

Anyway, I can always (pseudo):

Code: Select all

on mouseUp
   lock messages
   set the menuHistory of btn 1 to not the choice you currently want
   unlock messages
   set the menuHistory of btn 1 to the choice you do want
end mouseUp/code]

This way I can change the menuHistory without actually doing anything to whatever item 1 does, and still get "Choice 2" even if it is already at "Choice 2".

Craig

[jacque]

This way I can change the menuHistory without actually doing anything to whatever item 1 does, and still get "Choice 2" even if it is already at "Choice 2".

I'm trying to figure out why you'd want to do that.

[dunbarx]

Jacque.

Our postings are crossing in the mail between the two threads.

So why would anyone decide to select a comboBox menuItem that is already selected? But surely this might come up, if, say, you want to start a process again, simply based on the choices available. And if one is doing this remotely, it is even more likely that this might be desirable.

All the other menu-style buttons permit this without issue. I asked: "is it just that the current choice is displayed that made the authors decide to restrict that functionality in that particular style? I see no compelling reason for this at all. It caused me to waste some time trying to determine why a handler was failing.

Anyway, as I said, the fix is (pseudo):

Code: Select all

on mouseUp
   lock messages
   set the menuHistory of btn 1 to not the choice you currently want
   unlock messages
   set the menuHistory of btn 1 to the choice you do want
end mouseUp

Craig

[jacque]

Since I haven't seen a compelling reason for the behavior I think the team made the right decision. If you want to allow repeated selections though, try setting the menuHistory to 0.

[dunbarx]

Jacque

try setting the menuHistory to 0.

That makes the workaround a bit simpler.

Time to drop this, though i still cannot see why it was the "right" decision, as opposed to one that has no advantage at all.

Craig

[jacque]

The advantage would be to avoid repeated actions that might add redundant information to a data set. This way you don't have to keep track. Don't some operating systems disable the current selection? I can't remember.

I was going to drop this but my hind brain took over.

[dunbarx]

I only have a hind brain. Or maybe its a hind end.

You (re)started this.

So I have to go back to the fact that the only thing distinguishing the combo from the others is that the combo displays its current selection. What does that mean in the grand scheme of things? The user can see it, and, just a little, it may be odd or unusual to reselect the same menuItem.

But whatever that selection did is not usually obvious from a simple reading of the combo field. It is just a record of the last selection.

Ought that engender some sort of hand-wired "safety", to save the unwary user from doing such a dastardly deed? What is the downside? None that I can see, since the worst thing that can happen is a revisit of the previous process. Was it thought that, generally, would be dangerous, or at least useless? I don't see it at all.

I can accept it as a peculiarity, I cannot understand why it was deliberately made.

This is very academic, to be sure, And it isn't going to change. I just want everybody to agree with me. Politically, I am a Darth Vader libertarian. I want everyone to do my bidding, but of their own free will.

Craig