There seems to be a problem with this as of latest release (on macos anyway). I have a self.colorSequenceComboBox which is populated by a bunch of AddRow calls in its opening event, then me.SelectedRowIndex = 2 sets the item I want displayed initially.
Problem is this: when I later reset its text: self.colorSequenceComboBox.text = newText
newText gets clobbered and instead the combobox’s 1st row is always inserted into its .text property as reported by: dim debug_colorSequenceComboBox_Text as string = self.colorSequenceComboBox.Text
added right after.
The only way around this is to always: self.colorSequenceComboBox.SelectedRowIndex = -1
right before setting its text property. This did not happen before 23r2 and now forces me to sift through all my projects where I programmatically set the combobox.text property and want it to stick.
I hate to say it, but probably not. Not meaning to be negative but I’ve been filing reports on a persistent “DebuggerHook” crash for years, went to the trouble of stripping my project and submitting what I could, with no traction.
After recurrent crashes I filed a followup crashlog, and was asked to once again strip down a project and submit, which I declined to do. I simply don’t have time to waste on issues that don’t get attention. I’m hoping that Xojo will peruse the forum and scrape what they want and fix what they intend. Diminishing returns and all that.
Hello,
The text field of the combo box is just a text field
must be added to the combobox list before it can be displayed.
With selection -1 you have overridden the display and see your text.
My programming for example:
Insertion position here 0 can also be any other position.
well if it’s just a text field why does its contents get clobbered after a write new text to it with ComboBox1.text = “newText”? unless I first reset selectedRowIndex to -1.
This worked as expected pre-23r3 and r3.1 did not fix it.
The problem arises when you pre-populate the combobox with a bunch of AddRows, set the selectedRowIndex to what you want, but then come back and copy some arbitrary text into the box that may not even be part of its pre-populated list (the whole point of a combobox: a combo of preset and arbitrary strings). Your new text gets clobbered by some new event that is probably triggered after your ComboBox1.text = “newText” call that then resets the text to match the existing selectedRowIndex, not what you wanted.
It sets the combobox text to a string value read from a dict. Clearly this code should never break yet you can see it did: the combo box text is not what was read from the dict (it is always defaulted to 1st row of the combobox that was pre-populated at Open). If I precede this block with a SelectedRowIndex = -1 it runs as expected and never breaks. This behavior only began with 2023r3 and now r3.1.
