[RESOLVED] Showing Another Form

[Dim Wit]

I start a new project.
The 1st form's name = Form1.
In the Properties window I change the name to frmone.

I add another form via Project and Add Form (Windows Forms)...
The 2nd form's name = Form2.vb.
In the Properties window I change the name to frmtwo.

But my code doesn't work...

Private Sub frmone_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Dim frmtwo As New Form
frmtwo.show()
End Sub

Why do I have to declare frmtwo as a variable? The form already exists.

And apparently I have to set a reference to frmtwo, but I can't figure out how to do that.

So can someone please help me? Thanks.

[jmcilhinney]

You have a fundamental lack of understanding of OOP. Think about how types and objects work in the real world. If someone designs a new car, can you just drive off in that design? Of course not. They actually have to build a car based on that design and they generally build more than one. The same goes for your forms. You are just creating a design in your project. You are creating a type that has all the information required for creating objects of that type, just like a car design includes all the specifications for building cars of that type. At run time, you have to create an object based on that design. This line doesn't do what you want though:

Dim frmtwo As New Form

You say that you designed a form class named 'frmtwo' but you're not using it in that code. The variable name has no specific connection to the type. It is convention to use descriptive names because it makes code easier to read but that is convention only. That variable could be named anything, e.g.

Dim higgledypiggledy As New Form

Now do you see the issue? You are actually creating an instance of the Form class, NOT an instance of your 'frmtwo' class. You need to specify the type of the object you want to create:

Dim higgledypiggledy As New frmtwo

Now you have created an object of the correct type and assigned it to that variable, so you can call the Show method of that object via that variable:

Dim higgledypiggledy As New frmtwo
 
higgledypiggledy.Show()

The next step is to start using meaningful names for everything, including types and variables. What does "frmtwo" actually mean? Nothing useful. Name all your types so that they are self-documenting. For instance, if your startup form is the main form for the application then name it so, i.e. the default Form1 should be changed to MainForm or MainWindow or something similar. If you add a second form that is for editing User records then you can change Form2 to UserEditDialogue or the like. You can then name your variables sensibly too. If they are local and used in a very narrow scope then they don't need to be too descriptive, because the type name will provide the description, e.g.

Using dialogue As New UserEditDialogue
    If dialogue.ShowDialog() = DialogResult.OK Then
        '...
    Next
End Using

If the variable's scope is wider then you may need a more descriptive name so you always know what it is for.

[Dim Wit]

Yeah, I don't understand OOP and probably never will.
But I do understand code and I got it to work.
Thanks!

[jmcilhinney]

Yeah, I don't understand OOP and probably never will.

You don't have to be an expert to understand the basic principles. The whole premise of OOP is that programming objects behave like real-world objects so if you understand how real-world objects behave (you do) then you can understand how programming objects work. Please don't do as I see some people do and start out with the attitude that you can't and then use that as an excuse for not trying and then expecting others to pick up the slack. I would assume that the analogy about the car design being different to the actual cars that people drive was clear enough - I doubt you mistake one for the other - so what's the problem with understanding the difference between the form type you design and the form objects created and displayed at run time?

[Dim Wit]

Give me some time and I'll get back to you about this.

[jmcilhinney]

It's the sort of thing that tends to click all of a sudden. It depends how good at abstract thinking you are, because there's pretty much a 1:1 correspondence between real-world objects and programming objects, but the latter being abstract is the stumbling block for some people. I'll give you until this time tomorrow. If you haven't got it by then... take a bit longer.

[Dim Wit]

Now do you see the issue?

I think so. Here's what I'm thinking...

My goal was to create a second form.

So I added the second form (frmtwo) to the project.

But at this stage, my second form doesn't really "exist".

Instead, what exists is a class, a blueprint from which I can create objects (such as my second form).

So to make the second form "exist", I need to create an object from the frmtwo class.

Dim mycalculator As New frmtwo

And, now that my second form "exists", I can do things to it...

mycalculator.Text = ("My Calculator")
mycalculator.Show()

Surely that's right. Yes? No? Maybe?

It's the sort of thing that tends to click all of a sudden.

I've given up on that one big "Aha!" moment, however I have had some smaller "Aha!" moments and that in part has been due to your patience with me, so thanks JM.

[jmcilhinney]

Surely that's right. Yes? No? Maybe?

The correct answer is... YES! One thing to consider is that it is quite possible that you would want multiple instances of the same form type displayed at the same time. That wouldn't be possible if the form object was the thing you designed while creating the app. Just like you can create as many instances of other types as you like, so you can create as many instances of a form type as you like. The visual designer is just that: a designer. It's not an object creator.