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?
Popupmenu1
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
Popup2
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
PushButton
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. Nothing is wrong with your code otherwise.
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.
Idea:
*** 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
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.
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?
Nothing is wrong with your code otherwise. 
