PopupMenu not firing when selecting the same row

Testing in Xojo 2021v21 and v3 an app of mine built several years ago I noticed that selecting a row already selected won’t fire it anymore. Yet, it fires on a Mac.

For instance, create two Popupmenus with the same number of rows.
In Popupmenu1.change event have a msgbox tell you its text (nowadays, value).
Have the popupmenu set to row = 0

In the second Popupmenu’s change event
set: PopupMenu1.SelectedRowIndex = me.SelectedRowIndex

Now, if the two popups are set to the same SelectedRowIndex, nothing happens, while on a Mac, the first popup pops up the expected message.

Same behavior putting in the action event of a push button the following snippet:
PopupMenu1.SelectedRowIndex = PopupMenu1.SelectedRowIndex
Nothing fires.

Is this by design?

Sub Open() Handles Open
me.AddRow “John”
me.AddRow “Mary”
me.AddRow “Lucy”
me.SelectedRowIndex = 0
End Sub
Sub Change() Handles Change
MessageBox me.RowValueAt(me.SelectedRowIndex)
End Sub

Sub Open() Handles Open
me.AddRow “1”
me.AddRow “2”
me.AddRow “3”
me.SelectedRowIndex = 0
End Sub
Sub Change() Handles Change
PopupMenu1.SelectedRowIndex = me.SelectedRowIndex
End Sub

Sub Action() Handles Action
PopupMenu1.SelectedRowIndex = PopupMenu1.SelectedRowIndex
End Sub

The event will only be fired if the index changes. The index remains the same in your example (set self to self). If something remains the same, did it change? This behavior should be expected. :slight_smile: Nothing is wrong with your code otherwise. :raised_hands:

So this is the new expected behavior in Win apps. Good to know.

1 Like

It should’ve always been this on all platforms really…

The event is “changed.” Changing 0 to 0 is still 0, so the event shouldn’t fire. I can think of a few reasons this would pose an issue… Especially possible cyclical /stackoverflow issues under certain coding needs.

A work around for you, would be too set -1 index and then immediately call the desired index…

You would need to add something along the lines of…

if selectedrowindex = -1 then exit

at the top of your change events to ensure the change event is dropped when “nothing” is selected. Since the index would be set to -1 prior to calling the ‘same index,’ calling the matching index would then actually fire a change.

*** You could modify your code to place the change code into a method that checks the values of the indexes and does what’s desired. In that case, the code is easier to manage and control what happens from both “tied-together” controls, from one place (makes tracking bugs easier too). Then your events contain less code, invoking the method, making the logic in them easier to follow and maintain. Just an idea. There’s a dozen ways too reach the same means :slight_smile:

When I have to re-select the same row, I now do this:

dim prevIdx as integer = popupmenu1.listindex
#if targetWindows
popupmenu1.listindex = -1
popupmenu1.listindex = prevIdx

The real problem is that the behavior is different in Mac and Windows. I filed bug report #66755 last week about this.

1 Like

Greatful this was mentioned… I am writing code now where a no change “change” would have used an issue.

The work around would be to cache the state and check/save it in the change event.

BTW that behavior on a Mac applies to API 1 as well in 2019r1.1 (just tried it there) so it likely has been that way for a good while!

Feedback says it has already been fixed BTW.


The behavior (always firing) was common to Mac and Windows, back to years ago.
That’s why, in Windows, I noticed it in 2021: i.e. the change event was not firing anymore like in “old” behavior.
I did not check Mac API 2, nor Windows API 2.

Xojo could change it to “RowSelected”, for API 2 :grin:

Don’t give them any more ideas!!!


1 Like

Can you explain the use of firing multiple times the same code ?

It seems the class is doin exactly as it’s supposed to… Firing only if the value has changed.

Suppose the popupmenu contains a list of songs, with each row keeping the location of the folderitem.
While listening to a song, selecting the same row starts the song from the beginning.
The same as if you had the songs listed in a listbox and double-clicked the same row.

But the issue is not the effectiveness of the procedure, but that the behavior changed and we (at least I) did not know about it.
Again, I’d like to know what Xojo is going to do about it: keep a different behavior on Mac and Windows? Or have the same behavior?

Thank you for the explanation.

I use a Loudspeaker button instead to play a song, but that is me.

I first wonder what’s the expected behaviour on both systems, without Xojo being involved (in other words, when does each platform provide the event).