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

 

[Phill W.]

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]

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]

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.


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?

 

[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.