Home All Groups Group Topic Archive Search About

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

Author
1 Jul 2009 2:09 PM
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

Author
1 Jul 2009 3:19 PM
Tom Shelton
On 2009-07-01, Olaf Rabbachin <Olaf_NoSpam@IntuiDev.com> wrote:
Show quoteHide quote
> 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
--
Tom Shelton
Are all your drivers up to date? click for free checkup

Author
1 Jul 2009 4:24 PM
Olaf Rabbachin
Hi,

Tom Shelton wrote:

> 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

Bookmark and Share