All controls offer some kind of event to indicate that the value has been modified. For example, when you enter a textbox and begin typing with each keystroke there is a TextChanged
event. When opening a combobox and selecting a new item in the dropdown, you get a SelectedIndexChanged
event.
The trouble is that in many cases the change events signal a series of changes that represent some interim, unfinished state. e.g. When a user is typing his zipcode there's no reason to lookup the city and state or even attempt to validate it until the user finishes typing. When the user has focus on the shipping method combo and presses the up/down keys to navigate through the combo values as he attempts to find the one he wants there is no reason to assume the shipping method has been specified and thus apply it to the invoice. It may make sense to wait until he exits the combobox after paging through the values to signal that a shipping method has been selected. We don't want to be bothered by a series of interim states.
In our shop, we implemented a Finalized
event that is only triggered when the user starts making some manual change (as opposed to programmatic changes like setting the zipcode from the DB) and then later finishes up. This Finalized
event had to be handled differently for different controls; I'm not aware of any .NET features that would make providing this easier.
The only idea I now have is to try to use something like Rx (Functional Reactive Programming) to accommodate this. Any idea for a simple .NET approach that would facilitate this?
The Validating
and Validated
events work just fine; however, the names were misleading and so it never occurred to me that these were appropriate.
All credit to Hans Passant for his comment that solved this for me. (Hans, will redirect credit to you if you answer.)