Inherited form: prevent the Load-event from firing for inheritors

O

Olaf Rabbachin

Hi folks,

I have a base-form that allows for canceling the loading of the form
(during the Load-event).
If loading the form actually is canceled, I simply issue a .Close on the
base-form. However, the Load-event is still being fired for *inherited*
forms then. Also, calling .Dispose or .DialogResult=Cancel in the base-form
does not prevent the Load-event from firing for inheritors.

For that reason, I have already attempted to remove the Load-event for
inheritors by creating and assigning a designer-class and overriding
PostFilterEvents with <events.Remove("Load")>. But that doesn't seem to
change anything at all - the Load-event stays there for inheritors.
Maybe the fact that the designer inherits from ParentControlDesiger is
causing that?

Anyway, I need to find a way to prevent the Load-event from firing for
inheritors, if required. I'd prefer this to work without having to attach a
custom designer, but if that's be the only way, I'd be fine with that.
However, there just *must* be a way of dealing with this issue from within
the base-form (as opposed to inherited forms) as I don't know who will be
using the base form and thus cannot test for i. e. .IsDisposed from within
forms inheriting from the base-form ...

Any pointers much appreciated!

Cheers,
Olaf
 
T

Tom Shelton

Hi folks,

I have a base-form that allows for canceling the loading of the form
(during the Load-event).
If loading the form actually is canceled, I simply issue a .Close on the
base-form. However, the Load-event is still being fired for *inherited*
forms then. Also, calling .Dispose or .DialogResult=Cancel in the base-form
does not prevent the Load-event from firing for inheritors.

For that reason, I have already attempted to remove the Load-event for
inheritors by creating and assigning a designer-class and overriding
PostFilterEvents with <events.Remove("Load")>. But that doesn't seem to
change anything at all - the Load-event stays there for inheritors.
Maybe the fact that the designer inherits from ParentControlDesiger is
causing that?

Anyway, I need to find a way to prevent the Load-event from firing for
inheritors, if required. I'd prefer this to work without having to attach a
custom designer, but if that's be the only way, I'd be fine with that.
However, there just *must* be a way of dealing with this issue from within
the base-form (as opposed to inherited forms) as I don't know who will be
using the base form and thus cannot test for i. e. .IsDisposed from within
forms inheriting from the base-form ...

Any pointers much appreciated!

Cheers,
Olaf

In your base from, override the OnLoad method to handle the cancel logic. It
would look something like:

Public Class BaseForm
Private _cancel As Boolean

Public Sub New()

' This call is required by the Windows Form Designer.
InitializeComponent()

' Add any initialization after the InitializeComponent() call.

End Sub

Public Sub New(ByVal cancel As Boolean)
InitializeComponent()
_cancel = cancel
End Sub

Protected Overrides Sub OnLoad(ByVal e As System.EventArgs)
If Not _cancel Then
MyBase.OnLoad(e)
Else
Close()
End If
End Sub

End Class

HTH
 
O

Olaf Rabbachin

Hi,

Tom said:
In your base from, override the OnLoad method to handle the cancel logic. It
would look something like:
[...]

perfect - I'm now raising a FormLoading-event in my base-form that allows
for setting a Cancel-property. If that property has been set to <True>,
I'll close the form from within OnLoad.

Got to have to ask myself as to why I didn't think of OnLoad before
(scratching head) ...

Anyway. Thanks, Tom!

Cheers,
Olaf
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top