LiveCode Forums.

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: In the script of the regular button: 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

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.

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

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.

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

dunbarx wrote: ↑

Fri Jan 31, 2020 11:47 pm

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.

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):

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.

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):
Craig

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.

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

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.

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