Does instantiating and initializing work only when tied to button click?

Beginner question. How come I can do this:

Public Class Form1
    Private StudentsInMyRoom As New ArrayList

    Public Class student
        Public name As String
        Public courses As ArrayList
    End Class

    Private Sub btnCreateStudent_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnCreateStudent.Click

        Dim objStudent As New student
        objStudent.name = "Ivan"
        objStudent.courses = New ArrayList
        StudentsInMyRoom.Add(objStudent)
    End Sub

End Class

But I CANNOT do this:

Public Class Form1
    Private StudentsInMyRoom As New ArrayList

    Public Class student
        Public name As String
        Public courses As ArrayList
    End Class


    Dim objStudent As New student
    objStudent.name = "Ivan"
    objStudent.courses = New ArrayList
    StudentsInMyRoom.Add(objStudent)

End Class

In the second example, all of the objStudent.etc get squiggly underlined and it says "declarat开发者_如何学运维ion expected" when I hover over it. It's the same code except now it is not tied to clicking a button. Can't figure out what is the difference.

---

It's because the implementation needs to be in a method, the way you have it means the code couldn't possibly be executed, how would you reference this code from elsewhere?

It doesn't have to be tied to a click however:

    Private Sub AnyNameYouLike
        Dim objStudent As New student
        objStudent.name = "Ivan"
        objStudent.courses = New ArrayList
        StudentsInMyRoom.Add(objStudent)
    End Sub

Will work.

---

Rather than tell you how to fix this code directly, I'm going to explain what I think is going wrong with your thought process, so you can also do a better job writing code in the future.

What I see here is a simple misunderstanding for someone new to programming of how classes work. When you build and define a class, you are not (yet) allocating any memory in the computer, and you are not yet telling the computer to do anything. All you are doing is telling the computer about how an object might look at some point in the future. It's not until you actually create an instance of that class that anything happens:

Public Class MyClass
    Public MyField As String
End Class

'Nothing has happened yet

Public myInstance As New MyClass() 

'Now finally we have something we can work with, 
' but we still haven't done anything

myInstance.MyField = "Hello World"

'It's only after this last line that we put a string into memory

Classes can only hold a few specific kinds of things: Fields, Properties, Delegates (events), and Methods (Subs and Functions). All of these things in the class are declarations of something, rather than the thing itself.

Looking at your samples, the code from your second example belongs inside of a method.

If you want this code to run every time you work with a new instance of your class, then there is a special method, called a constructor, that you can use. That is declared like this:

Public Class MyClass
    Public MyField As String

    'This is a constructor
    Public Sub New()
        MyField = "Hello World"
    End Sub
End Class

However, even after this last example you still haven't told the computer to do any work. Again, you must create an instance of the class before the code in that constructor will run.

This is true of all code in all .Net programs anywhere. The way your program starts out is that the .Net framework creates an instance of a special object or form and then calls (runs) a specific method in that form to sort of get the ball rolling for your program. Everything else comes from there.

Eventually you will also learn about Shared items and Modules, that can (sort of) break this rule, in that you don't have to create an instance of the object before using it. But until you are comfortable working with instances, you should not worry about that too much.

Finally, I want to point out two practices in your code that professional programmers would consider poor practice. The first is ArrayLists. I can forgive this, because I suspect you are following a course of study that just hasn't covered generics yet. I only bring it up so you can know not to get too attached to them: there is something better coming. The second is your "obj" prefix. This was considered good practice once upon a time, but is no longer fashionable and now thought to be harmful to the readability of your code. You should not use these prefixes.