Bypassing Events

[Rex the Strange]

Hello All,

I don't know if this is possible, but I'll give it a shot, here. I'm
sick of writing the following line of code in control event handlers:

if not visible then exit sub

Is it possible to override whichever routine processes the event
handler list so that no events are fired if the control is visible?
Something like this, for example:

protected overrides sub handle_events
if visible then mybase.handle_events
end sub 'handleEvents

(of course, I know that there's no handle_events routine, but is there
an equivalent?)

Please advise and tia,

rts

[Miro]

I dont know if RemoveHandler would work.

You might be able to do everything in 'one sub / function' to add and remove
handlers.

But - when multiple events are raised at the same time you probably cant
guarantee you removehandler and addhandler would be processed first.

Miro

"Rex the Strange" <ro********@widgetinc.comwrote in message
news:ac**********************************@j40g2000 prh.googlegroups.com...

Hello All,

I don't know if this is possible, but I'll give it a shot, here. I'm
sick of writing the following line of code in control event handlers:

if not visible then exit sub

Is it possible to override whichever routine processes the event
handler list so that no events are fired if the control is visible?
Something like this, for example:

protected overrides sub handle_events
if visible then mybase.handle_events
end sub 'handleEvents

(of course, I know that there's no handle_events routine, but is there
an equivalent?)

Please advise and tia,

rts

[Phill W.]

Rex the Strange wrote:

I'm sick of writing the following line of code in control event
handlers:

if not visible then exit sub

Is it possible to override whichever routine processes the event
handler list so that no events are fired if the control is visible?

You're on the right track - you have to look at overriding here because,
by the time you're into an event handler, the event's already been
raised and it's too lateto do anything about it.

The conventional pattern for this sort of thing is something like this:

Class CustomLabel
Inherits Label

Protected Overrides Sub OnResize( ... )

If Not Me.Visible Then Return

MyBase.OnResize( ... )

End Sub

End Class

This approach will work with just about every event, using this
On[<event>] pattern.

Then just use your Custom Label instead of the standard one.

HTH,
Phill W.

[Rex the Strange]

On Nov 5, 7:26*am, "Phill W." <p-.-a-.-w-a-r...@-o-p-e-n-.-a-c-.-u-k>
wrote:

Rex the Strange wrote:

I'm sick of writing the following line of code in control event
handlers:

if not visible then exit sub

Is it possible to override whichever routine processes the event
handler list so that no events are fired if the control is visible?

You're on the right track - you have to look at overriding here because,
by the time you're into an event handler, the event's already been
raised and it's too lateto do anything about it.

The conventional pattern for this sort of thing is something like this:

Class CustomLabel
* * Inherits Label

* * Protected Overrides Sub OnResize( ... )

* * * *If Not Me.Visible Then Return

* * * *MyBase.OnResize( ... )

* * End Sub

End Class

This approach will work with just about every event, using this
On[<event>] pattern.

Then just use your Custom Label instead of the standard one.

HTH,
* * Phill *W.

I see. Not really the sort of solution I was looking for - this would
require overriding all native event handlers which is only one step
away from putting the code in each of my event handlers. I was hoping
there was a master function that I could override - one that calls the
handlers.

Oh well. Thanks, anyway, all.

rts.

[Patrice]

You may want to explain what is the original problem you are trying to
solve.

It looks like you found that costlty events are triggered even when not
needed ? You could perhaps prevent them from happening by not touching the
control in the first place (what kind of events do you try to prevent ?)

Even and if you don't need much design time support you could create this
control as needed when needed. This way you don't have to change anything
when not visible, actually it doesn't event exists (or removing it from the
controls tree could perhaps work thought I never tried such a thing).

Or a wise use of the WndProc ?

Or Phil solution possibly with overriding the Visible property to
automatically remove/add the handlers depending on the new and current value
etc...

Or is it just in a control you are creating ? (in which case I don't see any
other solution).

etc...

--
Patrice

"Rex the Strange" <ro********@widgetinc.coma écrit dans le message de
groupe de discussion :
5b**********************************...oglegroups.com...

On Nov 5, 7:26 am, "Phill W." <p-.-a-.-w-a-r...@-o-p-e-n-.-a-c-.-u-k>
wrote:

>Rex the Strange wrote:

I'm sick of writing the following line of code in control event
handlers:

if not visible then exit sub

Is it possible to override whichever routine processes the event
handler list so that no events are fired if the control is visible?

You're on the right track - you have to look at overriding here because,
by the time you're into an event handler, the event's already been
raised and it's too lateto do anything about it.

The conventional pattern for this sort of thing is something like this:

Class CustomLabel
Inherits Label

Protected Overrides Sub OnResize( ... )

If Not Me.Visible Then Return

MyBase.OnResize( ... )

End Sub

End Class

This approach will work with just about every event, using this
On[<event>] pattern.

Then just use your Custom Label instead of the standard one.

HTH,
Phill W.

I see. Not really the sort of solution I was looking for - this would
require overriding all native event handlers which is only one step
away from putting the code in each of my event handlers. I was hoping
there was a master function that I could override - one that calls the
handlers.

Oh well. Thanks, anyway, all.

rts.

[Rex the Strange]

You may want to explain what is the original problem you are trying to
solve.

It's not really a problem to be solved - more that I would like to
increase performance by not running the handler code for controls that
aren't going to be shown in the end, anyway.

It looks like you found that costlty events are triggered even when not
needed ?

That's exactly it. I can live with these handlers being called and
then exiting from them if the control is not visible (which is the way
I currently do it) but I just think that it would be nicer if I could
run this test in one place for all handlers. Surely there's a routine
that marches through the control list and fires the events? What is
that routine and is it overridable?

[Jack Jackson]

On Thu, 6 Nov 2008 09:38:36 -0800 (PST), Rex the Strange
<ro********@widgetinc.comwrote:

>

>You may want to explain what is the original problem you are trying to
solve.

It's not really a problem to be solved - more that I would like to
increase performance by not running the handler code for controls that
aren't going to be shown in the end, anyway.

>It looks like you found that costlty events are triggered even when not
needed ?

That's exactly it. I can live with these handlers being called and
then exiting from them if the control is not visible (which is the way
I currently do it) but I just think that it would be nicer if I could
run this test in one place for all handlers. Surely there's a routine
that marches through the control list and fires the events? What is
that routine and is it overridable?

In general there is no method that "marches through the control list"
to fire events. Each event does something specific to that event.
When a control is resized, the SizeChanged event is fired for each of
its children. Keyboard events raise events in the control with focus.
Mouse events raise events in the control underneath the mouse.

You have to be very careful if you want to simply ignore all events
when a control is not visible. You may need to fix things up when the
control becomes visible.

For example, suppose you have a control that is anchored to the bottom
of a form. If the control is invisible when the form is resized, and
you block events to the control, when the control becomes visible it
will be in the wrong place.

What events are you trying to not process?

[Patrice]

See Jack advice, wether or not it is a good idea may also depend on what
exactly you cancel as if the control is finally visible again its state
could be wrong.

If this is just something you "feel" would be quicker, you may want to
measure actual performance before doing such a change.

Also if you have actual performance problem, you could also investigate if
this is not a design or algorhitm issue (such as something causing a bunch
of events being triggered or something such as filling a list the wrong way
etc...)

If you have a problem generally it's better to ask about the original
problem rather than about the solution you try to apply, as describing the
original problem could lead someone to suggest a much better solution...
--
Patrice

"Rex the Strange" <ro********@widgetinc.coma écrit dans le message de
groupe de discussion :
e0**********************************...oglegroups.com...

>

>You may want to explain what is the original problem you are trying to
solve.

It's not really a problem to be solved - more that I would like to
increase performance by not running the handler code for controls that
aren't going to be shown in the end, anyway.

>It looks like you found that costlty events are triggered even when not
needed ?

That's exactly it. I can live with these handlers being called and
then exiting from them if the control is not visible (which is the way
I currently do it) but I just think that it would be nicer if I could
run this test in one place for all handlers. Surely there's a routine
that marches through the control list and fires the events? What is
that routine and is it overridable?

[Rex the Strange]

I just had a realization - and, yes, Jack, I appreciate your argument.
I did not make myself very clear, however. I'm actually talking about
asp.net, not applications development. I apologize for not making this
distinction earlier in the discussion.

In asp.net (using VB - perhaps I'm in the wrong discussion group?) all
events are processed before the page is rendered and it's these events
I'm talking about.

Sorry about the confusion.