I’m populating a WebPopupMenu and then setting the .SelectedRowIndex to a desired index, but setting it programmatically doesn’t prompt the SelectionChanged Event (which I was hoping it would).
Is there a reliable (best) way to programmatically set the index and cause a SelectionChanged Event? Thanks!
It should, but someone complained and Xojo hacked a way for it to not – breaking tons of my code.
I found a pre-release case, marked fixed & verified Xojo2020r1:
60168 - WebMenu Selection Changed Event not firing when selected row index set in code
I guess then someone complained and they changed the behavior because a year later the case has a request to reopen.
A new case still open:
65090 - WebPopupMenu SelectionChanged not firing when SelectedRowIndex changed in code
I do hope the desktop framework behavior (change event means it changed) gets brought to Web. It is far easier to set a flag to ignore than it is to implement a workaround for it not firing.
Heck, you can use the Enabled property and you don’t even have to create anything
if not me.Enabled then return
Some do the einhugur controls have in changed events a ByUser flag a boolean parameter. Maybe xojo could do the same
Couldn’t you just subclass the control, and replace the SelectedRowIndex with a computed property that Triggers the Server Event for the controlID & “SelectionChanged”? I use this method to force Xojo WebControls to fire events or in “make shift” custom-controls not using the webSDK (sometimes is MUCH faster and more efficient!). I will revisit this thread later but the process is not very difficult if you’ve worked with the WebSDK prior and current.
**When something doesn’t work - make it! 
ControlID.triggerServerEvent(“SelectionChanged”, null, false); <–JavaScript
Here’s the fix as a demo in case anyone wants to learn how to force a control event to occur whenever desired in Web Edition API 2.0. (Great for when events just don’t fire on their own or are broken 
)
Here’s the code that forces the event to fire…
Please note that the new documentation system is incorrect regarding this item. It says that the event is fired when the selection is changed manually or in code. It also says that you should change it in code using “ListIndex,” which is no longer a property of WebPopupMenu in Web 2.0.
Should I file a Feedback report about the documentation? I am not sure what to do when the documentation is linked to an open bug report (it is still open as of today).
Also, any advice about whether I should anticipate that this bug gets fixed or not? I am moving some code from Web 1 to Web 2, and will have to rewrite a lot of it if it is not fixed (though maybe Matthew’s idea will make this a bit less grievous). On the other hand, if the bug is fixed at some point, I will have to rewrite it all again.
Maybe @Ricardo_Cruz can review the feedback cases. Consistency between Xojo platforms (Desktop/Web/Mobile) is important to be easy for us to use the same login going from/to platforms.
X2
Matthew’s code (hack) works but the framework should behave consistently.
SelectionChanged should be firing if you change the index programmatically, to match how Desktop works. If it doesn’t in specific controls, please file a Feedback case, there are a few reported cases already fixed for next release.
I’ll review this control and fix it ASAP.
Thanks Tim