While the value change event for a listbox or multicolumn listbox is useful to see if the user clicked on a new row, I feel what I am most often concerned with is if any of the ITEMS changed. I suggest an item change event being added.
It fires even when you don't change the value of the item. So for instance, I had a flag I wanted to set if changes had been made so if the user leaves the screen it will prompt them to save or discard changes. But, I couldn't do this solely based off the edit cell because it didn't tell me if changes were made, just if the listbox went into "edit cell" mode (even if the user changed nothing).
All the events fire even when there's no change made. For example, Value(Signaling) fires even if the value is the same. This is consistent across all our events, and was behavior we consciously implemented. Doing the value comparision is often performance expensive depending on the size of data relative to the frequency of the event. Many apps do not have negative side effects if the event fires even if the value has not changed, so for them, the comparison test is often unwanted overhead. Thus we leave it to any app that needs to do the comparison to do it themselves in the event handler rather than make it a part of the event generation code -- just as you do in the picture you show.
I would not expect us to change this behavior for just this one event. Also, for the record, you should put your reading of the Items outside the While Loop and then update the value in a shift register, like this:
The reason this is important is because if you put the read inside the while loop, it may not get read until after the user has already changed the value, causing you to miss some value changes.
AQ, thanks for the advice. Also, I realized because a table has a datatype of a 2-D array, the change of an item would trigger the value change event, and then you could use the "mouse down?" event to manage clicks/new row selected. This is probably sufficient for most cases.
