Custom Objects are the foundation of OOP (Object Oriented Programming). An Object is a logical entity that can be referenced and manipulated using program code. It typically contains both a data portion and executable methods. For example, consider this fragment:
TextBox1.Text = "Hello, world!"
TextBox1.SelectAll()
The first line changes one of the Object's data properties, and the second line executes one of the Object's associated methods. Actually, to be slightly more precise, the fragment performs this work upon a specific Instance (TextBox1) of the general Object (TextBox). In the Visual Studio editor, IntelliSense helps you with the available operations, and it is smart enough to recognize what operations are appropriate for a particular Instance.
A Custom Object is pretty much what you would expect it to be. Instead of using just the Objects that are built into the .NET Framework, you create your own. You can instantiate (create Instances of) Custom Objects, just as you would with a TextBox or a Button. And IntelliSense will recognize the appropriate properties, methods, etc. The properties and methods comprise a standard interface to the Object.
It's possible to write some pretty powerful programs in Visual Studio without using Custom Objects. So... why do you need them? The main justifications are reusability and centralized maintenance. If you have a small Object that performs a limited number of tasks, you can reference it in many places and expect it to behave consistently. As you add features to the Object or fix bugs, you don't need to worry that you updated Program A but not Program B (because the code is in the Object, not in A and B). Disentangling the object logic from the rest of the program makes for shorter, cleaner code. In OOP terminology, communicating via an interface is called Abstraction, and hiding the program details is called Encapsulation.
Returning to the TextBox example, you wouldn't want to fill your program with complex Windows logic every time you display a TextBox. Abstraction simplifies your life by insuring that you deal with an Object conceptually. Encapsulation allows Microsoft to make underlying changes so that your program can run on Windows 2000, XP, Vista, Windows 7, new hardware, etc. without affecting you. They could change the underlying programming language altogether, and as long as the interface is compatible, you wouldn't care. Think of Encapsulation as a "Black Box" that you don't need to open.
The Person Object
Okay, let's create a Custom Object! Go into Visual Studio and choose "Create Project" and use the template Windows Forms Application. It will show you an empty Form1, which you should ignore for now. Go to "Project | Add Class" and use the template "Class". Name it "Person.vb", and press Add. Change the code to:
Public Class Person
Public FirstName, LastName As String
End Class
Well, there you have a very simple Custom Object. Now go back to your Form1 and double-click the form's surface. As you enter the following code, you'll notice that IntelliSense is aware of the appropriate choices.
Private Sub Form1_Load(ByVal sender ...
Dim p As Person
MessageBox.Show(p.FirstName)
End Sub
Click the "Play" button (green triangle in toolbar, or press F5). You'll get the notorious "Object reference not set to an instance of an object" message. This message means that although p is defined as a Person object, you have not invoked the appropriate initialization code to instantiate it. Make the changes below, and this will become clearer.
Private Sub Form1_Load(ByVal sender ...
Dim p As Person
p = New Person()
p.FirstName = "Joe"
MessageBox.Show(p.FirstName)
p = New Person()
p.LastName = "Smith"
MessageBox.Show(p.FirstName)
End Sub
This time, there is no error when you press Play. You created a New person instance p, so the first MessageBox shows Joe. The second MessageBox is empty, because you replaced the previous instance p with another new instance, and the new p has only a LastName.