[2008] What is best practice to abort startup and close form

[szlamany]

I've got a single form application.

In the Sub New() of that form I'm creating two database classes.

In those classes if I get database errors (such as connection issues) I'm messagebox'ing the error message and setting an ERRFLAG property.

Back in the Sub New() I'm checking that ERRFLAG and I thought I could ME.CLOSE() - but that's not working.

What all is best practice for this type of operation?

This is what I had up to now

    Sub New()

        Me.CMCStarting = True

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

        ' Add any initialization after the InitializeComponent() call.

        vendorBAL_C = New vendorBAL
        If vendorBAL_C.ErrFlag Then
            Me.Close()
            Exit Sub
        End If

        caseBAL_C = New caseBAL
        If caseBAL_C.ErrFlag Then
            Me.Close()
            Exit Sub
        End If

        Call vendorLoad()

        Call caseLoad()

        Me.CMCStarting = False

    End Sub

[chris128]

Would you not be better off doing this in the Form Load event? I've not seen anyone use the constructor (Sub New) of a form for anything other than creating the controls that are going to be on that form.

[szlamany]

Probably so - I was about to rip this stuff out and go there...

I think the only reason this started in the NEW() was back when we were prototyping some of this we were binding controls - and thought that doing that in NEW() was best...

[chris128]

Well by all means wait for someone with more experience to post before you go scrapping it all if you want as thats just my opinion and I'm no expert... but like I said, if it was me I would definitely be doing that kind of thing in the form load event.
Also, if you ever need to close the app but for some reason cant call Me.Close I think Application.Exit should do it There's probably some good reason why you shouldn't normally use that command but hey its gotta be there for a reason.
Just to clarify, You can call Me.Close from the Form Load event though.

[szlamany]

Thanks

This worked better.

    Private Sub CMCConsole_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

        Me.CMCStarting = True

        vendorBAL_C = New vendorBAL
        If vendorBAL_C.ErrFlag Then
            Me.Close()
            Exit Sub
        End If

        caseBAL_C = New caseBAL
        If caseBAL_C.ErrFlag Then
            Me.Close()
            Exit Sub
        End If

        Call vendorLoad()

        Call caseLoad()

        Me.CMCStarting = False

    End Sub

But I'm still eager to hear some more opinions.

[stanav]

I'd start the application from a shared sub main. In this sub, I'd create the necessary DB connections... and if succeed, I'll go on instantiate the form and show it, else I exit the app.

[szlamany]

I'd start the application from a shared sub main. In this sub, I'd create the necessary DB connections... and if succeed, I'll go on instantiate the form and show it, else I exit the app.

And still do MESSAGEBOX.SHOW's from that SUB MAIN?

[stanav]

And still do MESSAGEBOX.SHOW's from that SUB MAIN?

Yes... Why can't you? If the sub main is in a separate class, all you have to do is to fully qualify the class name or imports the System.Windows.Forms namespace.

[szlamany]

I'm just asking stupid questions...

I don't do much .net coding - I'm a sql programmer for the most part with a pile of old VB6 programs we've used for the past 10 years

[chris128]

What advantage does that have over just doing it in the Form Load event though? I suppose you might save about a second or something where you would of been waiting for the form class to be instantiated but isn't that the only difference?

[szlamany]

I'm leaning of leaving it in the FORM_LOAD because most of what happens after the SQLDataAdapter/DataTables/DataSet are created in the CLASS is that they are bound to control objects anyway...

[stanav]

What advantage does that have over just doing it in the Form Load event though? I suppose you might save about a second or something where you would of been waiting for the form class to be instantiated but isn't that the only difference?

What advantage? The form only gets created when needed... There's no point in creating a form and then destroying immediately because you find out that you don't need it... If you can check to see whether the form is needed in 1st place, why not doing so?

[jmcilhinney]

The correct way to do this in VB 2005 and later is to handle the Startup event of the application. You do your application initialisation there and, if it fails, you set e.Cancel to True. That's it. The startup form will never be created and the app will exit gracefully. The application events like Startup and Shutdown are generally used INSTEAD of a Main method when the Application Framework is enabled, which it is by default. You can disable the Application Framework and use your own Main method (instead of the one that is otherwise hidden within auto-generated code) but, really, why would you?

[chris128]

Now I see why Max was so fascinated by the Startup event

[jmcilhinney]

Now I see why Max was so fascinated by the Startup event

[MaximilianMayrhofer]

You guys have got to let that go! I learned C# before VB, it's not my fault the language offers greater control