When does SelectedIndexChanged event fire & an alternative to this event?

[moondaddy]

I am experimenting with different ways to handle the selecting items from a
combo's dropdown list. Typically I use the selected index changed event to
do something with the new item selected in the list. However, I also use
some custom methods to simulate an autocomplete combo when the user types
text into the combo and also when the focus leaves the combo. So here's
what I'm wondering:

Often the datasource of the combo is a dataset and when I do something like
edit the dataset or re-populate it the SelectedIndexChanged event fires
which takes up resources and sometimes causes bugs in my code. So I try to
put a flag at the beginning of the event procedure where if the flag = True,
then exit the procedure. If I get rid of this SelectedIndexChanged event
procedure all together, will this be much cleaner and a more efficient
execution of code? If so, then the code I would have executed in the
SelectedIndexChanged event procedure can be called from my custom methods
used for the autocomplete effect. By doing this I think I'll have more
control over precisely executing code when an item has been properly
selected in the dropdown list and avoid unnecessary execution of the
SelectedIndexChanged event.

Comments and opinions?

 

[Ying-Shen Yu[MSFT]]

Hi moondaddy,
I think you are intending to skip all the SelectedIndexChanged event.
You may try deriving from the ComboBox and override the
OnSelectedIndexChanged method, just comment the base.OnSelectedIndexChanged
event. This will skip firing the event in SelectedIndexChanged as well as
some sync codes of internal data-binding.
Does it solve your problem?
If you still have questions on this issue, please be free to reply to the
group.
Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
You should not reply this mail directly, "Online" should be removed before
sending, Thanks!

 

[Billw]

Hi - I have experienced simliar problems when working with Forms.
Typically, I do something similar to what is suggested by having the event
handler test a flag which is set when the event is to be ignored -- kind of
a "just ignore" flag.
As an aside, I am used to using MFC when dealing with complex dialogs MFC
has formalized this technique by checking for a current control window when
a parent window receives messages from a control. MFC data transfer
routines record the current control window during the data transfer to the
dialog (or window) to allow the source of notification messages to be
checked against the current control window during the data transfer process.
If it matches, the notification is ignored. If not, the notification is
processed. This prevents the notification message from being reflected to
the parent window when the data transfer routines change the control's
content.
I think this is an omission in Forms that is very useful when constructing
complex windows or dialogs. If such a technique is implemented in Forms, I
haven't found it yet. Like you, I would be interested in how others treat
this problem.
Billw