Conclusion

Conclusion

We've covered quite a bit in this chapter. Let's recap. First you learned that a class is a blueprint for an object; the actual object is a manifestation (or instance) of that class. A class can inherit capabilities from a parent, or base, class. A class has properties that contain information about its state, such as its size or color. The internal variables that hold the properties are called fields when they are referred to inside the class. A class also has code that instructs it to do things. From outside the class, these actions are known as methods. Inside the class, subroutines and functions implement a class's methods.

A class has a constructor, Sub New, that builds an object of the class, as well as a destructor, Sub Dispose, that tears down the class. When you want a new instance of a class, the New keyword usually will call a function named Sub Main, which in turn calls Sub New. If the class inherits from a parent class, the first line in the constructor calls the constructor of the parent class. All of the base classes are instantiated from top to bottom, with our class being last.

Within Sub Main is the line System.Windows.Forms.Application.Run(New Form1). The Application class's Run method calls Form1's constructor to build the class. Then the Run method executes an internal message loop that looks for Windows messages directed at Form1. When the Run method receives a message such as a button click, it directs the message to the form, which further directs the message to the button.

Each form or visible object has its own numbered handle. A handle is used by Windows to keep an internal list of which object (form, button, label, and so on) is which. The operating system uses handles to direct specific messages to specific programs to be intercepted by the Run method.

We also touched on events. Anyone who has programmed in a Windows environment is familiar with them. An event notifies our program that something interesting has happened. Our program finds out about events from the Application.Run method.

When we need to hide data within our class, such as we did with the iFormCounter integer variable that held the number of Doppelganger forms, the Private access modifier is used. There are also the Public, Protected, and Friend modifiers. Because we wanted only one counter to hold a value for all the forms, we used the Shared keyword. Using Shared makes sure that all the instances of the Form1 class use the same variable. When we initialized iFormCounter, we used the new capability of Visual Basic .NET to initialize the variable on the same line as we declared it. Because we were incrementing iFormCounter, we examined the new notation that permits us to do things such as iFormCounter += 1.

I explained and illustrated method overloading using the MessageBox class. By modifying the number of parameters, the MessageBox class has several functions with the name Show, but each version has a different signature. The Show function whose signature matches the parameters passed in is the one that's called. While looking at the MessageBox class, we covered the various constants that permit us to customize a message box for the task at hand.

Next we touched on polymorphism, which means "many forms." In object-oriented programming, polymorphism means "do the right thing." Calling Form1.Size and Text1.Size ensures that each object knows how to resize itself. While there is more to polymorphism, the endgame is that each object will "do the right thing."

We also covered namespaces, or the hierarchical notion of grouping logical classes. We examined a table that shows how the major functionality in the .NET Framework is grouped. In the frmTime class we created, we imported a namespace, System.Globalization, and used one of its classes so that we could use the local culture format. Then we examined various date and time formats and customized our class to modify the way it displays the output.

As your programs grow in sophistication, you'll need to add references to the namespaces where additional functionality lives. We illustrated how to bring up the Add Reference dialog box in the Solution Explorer and add the required reference. In the frmTime form, we imported our own namespace and used some date-formatting capabilities. Everything we did in this chapter was inside a class. I think you will agree that we covered quite a bit of ground here. I strongly recommend that if anything in this conclusion is unclear or fuzzy, go back to the text and read the specific section again. Understanding these concepts is necessary to fully understand Visual Basic .NET or any other object-oriented language.