2nd event triggered within an event handler

[=?Utf-8?B?TWF4IDFlNg==?=]

I have two events (a and b) each with its own handler. Unfortunately, event b
is sometimes trigered by an action within a's handler causing a's handler to
abort prematurely and service the b event.

Is there a way to disable the b event inside the procedure for handling the
a event?

Is there another approach I should consider?

[=?Utf-8?B?S2VycnkgTW9vcm1hbg==?=]

RE: 2nd event triggered within an event handler

Max 1e6,

A's handler should not be aborting. Instead, B's handler should run and then
control should return to A's handler.

However, you can use RemoveHandler at the beginning of A's handler to remove
B's handler. You can then use AddHandler at the end of A's handler to add
back B's handler.

Kerry Moorman


"Max 1e6" wrote:

I have two events (a and b) each with its own handler. Unfortunately, event b
is sometimes trigered by an action within a's handler causing a's handler to
abort prematurely and service the b event.
>
Is there a way to disable the b event inside the procedure for handling the
a event?
>
Is there another approach I should consider?

[=?Utf-8?B?TWF4IDFlNg==?=]

RE: 2nd event triggered within an event handler

Thanks, it is good to know how to kill an event if I need too. And it turns
out, as you know and I thought I knew, that it wasn't required in my case.

I don't know what I was seeing yesterday. It seems to have "gotten better"
just by resting overnight.

I had a list box and some textboxes. The list box had a SelectedIndexCh anged
event which changed the text in a textbox which also had a TextChanged event.
It was clear that all subsequent code was not executing after the TextChanged
branch. But as I say, it seems to have healed-up like a horse in the barn.





"Kerry Moorman" wrote:

Max 1e6,
>
A's handler should not be aborting. Instead, B's handler should run and then
control should return to A's handler.
>
However, you can use RemoveHandler at the beginning of A's handler to remove
B's handler. You can then use AddHandler at the end of A's handler to add
back B's handler.
>
Kerry Moorman
>
>
"Max 1e6" wrote:
>

I have two events (a and b) each with its own handler. Unfortunately, event b
is sometimes trigered by an action within a's handler causing a's handler to
abort prematurely and service the b event.

Is there a way to disable the b event inside the procedure for handling the
a event?

Is there another approach I should consider?