any way to suspend events for controls while I edit them?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

If I have a control like say a drop down list and I have some kind of
onSelectItem change event, is there a way to temporarily suspend the event
handling (without removing the event and then re-attaching it?) while I edit
it's contents which would otherwise cause the event to fire?

Or is there maybe a way in my event handler to tell if the user triggered it
as opposed to the program itself?
 
Or is there maybe a way in my event handler to tell if the user triggered it
as opposed to the program itself?

I faced the same problem some time ago.
I used, I'd say, a not so elegant way to solve this, but it worked for
me.
I used a bool value to indicate that the value is changed by me,
programmatically.
Like this:

class myClass {
private bool m_flag = false;
//...other members
private void someMethod() {
m_flag = true;
try{
//change the index of your combobox here; this will
autommatically call MyHandler() - see below
}
finally{
m_flag = false;
}
}
}

inside the event handler that handles the event:

private void MyHandler(EventHandler e) {
if(m_flag)
return;
//...code
}

As I said, it doesn't look very pretty to me, but it worked for me.
If anyone has a better solution, I'm also interested.

Thanks.
 
MrNobody said:
If I have a control like say a drop down list and I have some kind of
onSelectItem change event, is there a way to temporarily suspend the event
handling (without removing the event and then re-attaching it?) while I
edit
it's contents which would otherwise cause the event to fire?

Or is there maybe a way in my event handler to tell if the user triggered
it
as opposed to the program itself?

When do you "edit" the contents of the control? At design time? Run-time?
If at design time, do you want to suspend the events always at design-time?

I'm a little confused on this :)

Mythran
 
nano2k said:
I faced the same problem some time ago.
I used, I'd say, a not so elegant way to solve this, but it worked for
me.
I used a bool value to indicate that the value is changed by me,
programmatically.
Like this:

class myClass {
private bool m_flag = false;
//...other members
private void someMethod() {
m_flag = true;
try{
//change the index of your combobox here; this will
autommatically call MyHandler() - see below
}
finally{
m_flag = false;
}
}
}

inside the event handler that handles the event:

private void MyHandler(EventHandler e) {
if(m_flag)
return;
//...code
}

As I said, it doesn't look very pretty to me, but it worked for me.
If anyone has a better solution, I'm also interested.

Thanks.

I use essentially the same solution. It may not be pretty, but it's
prettier than unsubscribing and re-subscribing to events, which gets
uglier and uglier as the number of controls grows....
 
by using a drop down like that have you thought of making a new type of drop
down that reacts differently?

So like

class EditDropDown : DropDownList

and then change that drop down to react differently in the circumstances. So
you could override the event handler to pass the boolean value that it was
changed by you or not by you. Allowing your code using it to be much neater
but using the same methodology. Then the control itself could do all the
working out for you, you just check the boolean. Make sense?
 
I have to add, i am with Mythran, i am confused by this also but 'boing with
the flow' my other answer is stil how i would do it. Tho as i was writing it
i was thinking i have no idea how you will set that bool that you changed
the data. But anyway.....
 
Setting the bool is simple. To understand how it works, you have to go
back to the original problem, which restated, looks like this:

"Have event handlers that I want to invoke whenever the user
manipulates a control, but I don't want to invoke them when I
manipulate the control from within my program."

Unfortunately, the .NET framework doesn't provide a mechanism for
distinguishing between events that result from user actions from events
that result from you messing with the controls in your program. Cue the
boolean.

All you do is create a boolean in your class:

private bool _programIsChangingControls = false;

Then, whenever you write some code that populates a ComboBox, or
changes check boxes in a ListView, or something like that, you do this:

private void SomeFunction()
{
this._programIsChangingControls = true;
this.comboBox1.SelectedItem = ... ;
this._programIsChangingControls = false;
}

and then, in your event handler:

private void comboBox1_SelectedIndexChanged(void sender,
System.EventArgs e)
{
if (!this._programIsChangingControls)
{
... handle the event ...
}
}

I do the same sort of thing with validation routines: unfortunately the
Framework doesn't provide a way to cancel pending validation events, so
I just create a flag that tells the event handlers to not bother
validating, then when I need to flush validation events I set the flag,
force validation, and unset the flag.
 
Oh i see!

So he wants the event to not fire when his CODE changes the value not HIM as
a person clicking as it implied before. I get it now.

Umm, for a list box for the user to change the value they would have to
first click the mouse button or some other input key right? Could you not
make a new control that inherits from the listbox control, and have the
boolean set by that mouse click? Or something similar to distinguish a user
change over your own? That would be one way of a generic way of reading the
user, which would allow a control that only fires that even on a user change
as oppose to a code change of the value.

It all depends on the timing of the event si guess. Does the event fire
once a user has highlightes a new option and clicks the mouse on it?
Similarly does it fire if they press the up or down key when the control has
focus?

You could use focus as a check, override the selection changed event in your
inherited control to say if has focus and mouse clicked or key pressed then
user change so fire event for change made and pass vars in. Otherwise dont
fire event. Would that work?
 
Daniel said:
Oh i see!

So he wants the event to not fire when his CODE changes the value not HIM
as a person clicking as it implied before. I get it now.

Umm, for a list box for the user to change the value they would have to
first click the mouse button or some other input key right? Could you not
make a new control that inherits from the listbox control, and have the
boolean set by that mouse click? Or something similar to distinguish a
user change over your own? That would be one way of a generic way of
reading the user, which would allow a control that only fires that even on
a user change as oppose to a code change of the value.

It all depends on the timing of the event si guess. Does the event fire
once a user has highlightes a new option and clicks the mouse on it?
Similarly does it fire if they press the up or down key when the control
has focus?

You could use focus as a check, override the selection changed event in
your inherited control to say if has focus and mouse clicked or key
pressed then user change so fire event for change made and pass vars in.
Otherwise dont fire event. Would that work?

Another way would be to have a method that changes the value and doesn't
raise the event. This method would just change the internal members of the
control w/o raising the event while the property still calls the OnXXXChange
method which raises the event.

HTH,
Mythran
 
Back
Top