According to the docs, a Listbox Change event will fire when:
When the Listbox is clicked to give it the focus
When an empty row in the ListBox is clicked
When a cell is clicked even if it already is selected and the column is not editable
When a row is clicked to change the selection
Shouldn’t it also fire when we add or delete rows/folders via code? Also, those all seem to be more aligned with “GotFocus” than “Change” because they all are caused by a user’s clicking in the ListBox rather than a content or state change.
Am I just being dense today? I can’t think of a negative to that. Anyone else?
[quote=427032:@Tim Jones]According to the docs, a Listbox Change event will fire when:
When the Listbox is clicked to give it the focus
When an empty row in the ListBox is clicked
When a cell is clicked even if it already is selected and the column is not editable
When a row is clicked to change the selection
Shouldn’t it also fire when we add or delete rows/folders via code? Also, those all seem to be more aligned with “GotFocus” than “Change” because they all are caused by a user’s clicking in the ListBox rather than a content or state change.
Am I just being dense today? I can’t think of a negative to that. Anyone else?[/quote]
maybe add in a boolean IsLoading and set it to true when adding the row and set it back to false when done and on the listbox on change event, add some code to check if Isloading is false then do whatever else do nothing
[quote=427032:@Tim Jones]According to the docs, a Listbox Change event will fire when:
When the Listbox is clicked to give it the focus
When an empty row in the ListBox is clicked
When a cell is clicked even if it already is selected and the column is not editable
When a row is clicked to change the selection
Shouldn’t it also fire when we add or delete rows/folders via code? Also, those all seem to be more aligned with “GotFocus” than “Change” because they all are caused by a user’s clicking in the ListBox rather than a content or state change.
Am I just being dense today? I can’t think of a negative to that. Anyone else?[/quote]
The Change event is related to a change in the users selection as opposed to a change in the listbox contents. If you wanted something like that, you could certainly subclass the listbox, create a ContentsChanged event definition and then override the AddRow, RemoveRow, etc methods to raise the event and then call their supers like this:
Sub AddRow(txt() as String)
Super.AddRow(txt)
RaiseEvent ContentsChanged
End Sub
After, since you probably don’t want the Change event to fire until after you’ve added the new data.
One other thought. If you’re adding data and the user has already made selections, you may wish to record the current selections in an array and then reselect them after the added data. That would result in the same affect and result as my not above while retaining the user’s selections.
