Inheritance

Inheritance

As you can see, a form is a pretty smart object. It has all sorts of properties and methods that you can use immediately because they are part of the base class (also known as the parent class) that the form object inherits from. As I've said, inheritance is one of the fundamental tenets of object-oriented programming. Through inheritance, you can derive classes from other classes that have already been written. In our example, the base class is System.Windows.Forms.Form.

Public Class Form1     Inherits System.Windows.Forms.Form

When a class inherits from a base class, it inherits the properties and methods of that class. Properties and methods are often referred to as the members of a class. You can then use or add to these members in your own class in whatever way you need.

The Buffed Up Message Box

The message box we're using in this example is a tried and true friend of the Visual Basic programmer, but a few changes have been made to the message box that classic Visual Basic programmers should note. In Visual Basic 6, the MsgBox function supported optional arguments to specify a Help topic that would be displayed when the user pressed F1. Because the underlying mechanism for displaying Help topics has changed significantly in Visual Basic .NET, the HelpFile and Context arguments have been eliminated.

The older MsgBox syntax is still available in Visual Basic .NET. The Microsoft.VisualBasic.Interaction class exposes a MsgBox method that approximates the functionality of the Visual Basic 6 MsgBox function. However, I suggest you move to the new MessageBox class. It's entirely possible that in later versions of Visual Basic .NET, legacy Visual Basic syntax will be eliminated. By using the Show method of the MessageBox class, System.Windows.Forms.MessageBox provides fairly extensive support for informing and instructing the user.

Sometimes a user must dismiss a message box before continuing. Forms and dialog boxes can be displayed as either modal or modeless (the default). A modal form or dialog box must be closed (hidden or unloaded) before you can continue working with the application. Most forms, however, are displayed as modeless forms, which means that you can switch from one form to another by simply clicking the form you want to be active. Dialog boxes or message boxes that display important messages should always be modal. The user should always be required to close the dialog box or respond to its message before proceeding.

At times you might want to show a form modally, such as a form you've customized for entering a password or logging in. You want the user to address this form before moving on. Simply call the form's ShowDialog method to accomplish this.

mydialog = New Dialog1() mydialog.ShowDialog()

Understanding Namespaces

A large part of the power of Visual Basic .NET comes from the base classes supplied by the Microsoft .NET Framework. Microsoft has provided a vast array of ready-built classes for your use. The .NET Framework includes a variety of base classes that encapsulate data structures, perform I/O, give you access to information about a loaded class, and provide ways for you to perform rich GUI generation and data access and develop server controls. These built-in types are designed to be the foundation on which all .NET applications, components, and controls are built.

These base classes are simple to use, and you can easily derive from them to include their functionality in your own specialized classes. To bring some order to this power, the .NET base classes are grouped into what are called namespaces. As I mentioned earlier, our form is an instance of the System.Windows.Forms.Form class. In other words, the form lives in the .NET Framework namespace dedicated to Windows client user interface programming.

Think of a namespace as a container for related classes in the same way that a folder on your hard drive contains related files. In a .NET program you'll make use of many of the base classes, and any significant Visual Basic .NET program that you develop will have many more of your own namespaces. (I'll describe how to create your own namespaces in Chapter 3.) Having a firm understanding of the concept of namespaces is required before you do just about anything in Visual Basic .NET.

Because we need a way to identify and find the built-in items required for a program, the .NET Framework types are named using a dot-syntax naming scheme that connotes a naming hierarchy. You can see this syntax in the familiar class System.Windows.Forms.Form.

Public Class Form1     Inherits System.Windows.Forms.Form

This syntax tells us that the Form class is related to other classes that use the System.Windows.Forms namespace. These classes, representing objects such as graphical controls, are all part of the namespace. The part of the name up to the last dot (System.Windows.Forms) is referred to as the namespace name, and the last part (Form) as the class name. These naming patterns group related classes into namespaces and are used to build and document class libraries. This naming syntax has no effect on a class's visibility, how you access its members, how your classes inherit from the class, or how the linker binds your code.

As you've seen, the root namespace for the types in the .NET Framework is the System namespace. This namespace includes classes that represent the base data types used by all applications. These include Object (the root of the inheritance hierarchy), Byte, Char, Array, Int32, String, and so on. I'll review Visual Basic .NET data types in more detail in Chapter 4, "Visual Basic Data Types and Features."

Along with the base data types, the System namespace itself includes almost 100 classes. These classes range from those for handling exceptions (errors) and events to those dealing with core run-time concepts such as application domains and the automatic memory manager. Since it's impossible to cover everything about .NET in a single book, my goal is for you to work with these built-in classes enough that you'll be able to find what you need on your own.

In addition to the base data types touched on above, the System namespace contains 24 second-level namespaces. Table 2-1 lists the categories of functionality that are built in and the namespaces in each category.

Table 2-1  Second-Level Namespaces in the System Namespace

Category

Namespace

Data

System.Data

System.Xml

System.Xml.Serialization

Component model

System.CodeDom

System.ComponentModel

Configuration

System.Configuration

Framework services

System.Diagnostics

System.DirectoryServices

System.Management

System.ServiceProcess

System.Messaging

System.Timers

Globalization

System.Globalization

System.Resources

Network programming

System.NET

Programming basics

System.Collections

System.IO

System.Text

System.Text.RegularExpressions

System.Threading

Reflection

System.Reflection

Rich, client-side GUI

System.Drawing

System.Windows.Forms

Run-time infrastructure services

System.Runtime.CompilerServices

System.Runtime.InteropServices

System.Runtime.Remoting

System.Runtime.Serialization

Security services

System.Security

Web services

System.Web

System.Web.Services

Revisiting the Solution Explorer

Open the Solution Explorer by selecting View|Solution Explorer in the IDE. Click the References entry to expand it, and you'll see the items shown in the following illustration. The list contains the default references for a project. Even though namespaces live in assemblies (i.e., files), the Solution Explorer displays the namespaces, and it's more helpful to us to know the namespace than it is to know the particular assembly.

Of course, if you use any of the base classes that are defined in libraries, you need to ensure that the Visual Basic .NET compiler knows where to look for them—you need to understand how the compiler finds the namespaces you import. In more sophisticated projects later in the book, you'll import namespaces that are not among the defaults. You'll have to add references to these namespaces so that the compiler can probe the assemblies and find them. To add a reference, right-click References in the Solution Explorer and select Add Reference to open the Add Reference dialog box, shown here.

The namespaces are listed in the Component Name column. You can also see the version and the path that provides the fully qualified reference to the assembly file where the namespace items are housed. Don't select anything now. This glimpse is just to round out our exploration of the IDE for a project.

Inheriting from System.Windows.Forms.Form: Forms and Controls

The Windows.Forms namespace contains more than 300 entries, so it has quite a bit of functionality already built for you. This functionality enables a Visual Basic .NET programmer to be more productive than ever.

The Form class is the template used to create the form object at run time. When a form is displayed, an instance of the System.Windows.Forms class is created and can then be used like any other object. Class inheritance occurred in classic Visual Basic, except that it was hidden from you.

An important first step in developing any Windows Forms application is to implement the user interface. Because a .NET Windows program is typically a rich client application, the user interface is made up entirely of various Windows Forms controls. The Forms class as well as user interface controls classes such as Button and TextBox also live in the System.Windows.Forms namespace. Because forms and controls inherit properties and methods, using form and control objects permits an application to handle the low-level details; for example, when a user clicks a button.

Essentially, the Windows Forms framework encapsulates (hides the details of) native Win32 application programming interfaces (APIs). The framework then exposes secure, managed classes to the programmer for creating Win32 client-side applications. The Windows Forms framework also provides many controls—buttons, check boxes, drop-down lists, combo boxes, data grid, and other graphical and nongraphical gizmos—that encapsulate all sorts of functionality.

Like any other object, a control is a black box of functionality. For example, when you draw a button on a form, the button is born knowing how to respond to events such as a mouse click, a mouse hover, or even moves of the mouse wheel. The implementation of how the control intercepts operating system messages and converts them to events is hidden from you. You simply respond to any of the events that are important to you. You reuse OPC (other people's code).

A cool thing about the Visual Basic .NET IDE is that when you drop a control from the toolbox onto the surface of a form, all the boilerplate code that a programmer needs to use the control is automatically generated for you by the Visual Studio .NET Windows Forms Designer. This way, you can focus on writing the code that is specific to your application.

Each form created from the Forms class has the same initial property values for each instance. Table 2-2 lists the default values.

Table 2-2  Default Values for Form Class Properties

Property

Value

BorderStyle

FormBorderStyle.Sizable

ControlBox

True

MaximizeBox

True

MinimizeBox

True

StartPosition

FormStartPosition.WindowsDefaultLocation

WinForms.Form.ShowInTaskBar

True

WindowsState

Form.WindowsState.Normal

AutoScale

True

Using the form's Properties box, you can change these properties or any others that are displayed. The Designer takes care of updating the form's class code to reflect the changes. As you saw earlier in the chapter, you can also modify the form's properties programmatically during run time.

A Word About Visual Basic .NET Controls

Keep in mind that a control such as a button can't exist in a vacuum. It must be hosted by a form. The control is sited on the form and initialized. You can see in the previous code examples that the button control is declared and some of its properties are set within the form's class. A form object and its control objects form a symbiotic relationship. Later in the book, you'll create your own Visual Basic .NET controls that can be used in your project or any other .NET project written in any .NET language. However, you can see from the toolbox, shown in Figure 2-5, that enough built-in (intrinsic) controls come with Visual Basic .NET to keep us happy for a while.

tip

Select View | Toolbox from the IDE main menu and dock the toolbox on the left side of the IDE, if necessary. Right-click the caption bar and select Auto Hide. This command keeps the toolbox hidden on the left side of the IDE. When you need a tool, simply move the mouse over the box that says Toolbox and it will slide out. This setting keeps the toolbox handy, and you don't always have to explicitly request it from the View menu of the IDE.

Figure 2-5

The Visual Basic .NET toolbox.

note

As I touched on in Chapter 1, COM is no longer the preferred method of binary compatibility, but you can import COM and ActiveX controls created in classic Visual Basic to a .NET form. However, a Visual Basic .NET form can only host the new Windows Forms controls, and an ActiveX control can be hosted only in an ActiveX control container, such as a classic Visual Basic form. The Windows Forms ActiveX Control Importer (Aximp.exe) program can help you. It can convert the type definitions found inside a COM type library of an ActiveX control into a Windows Forms control. Aximp.exe generates a "wrapper" control, derived from System.Windows.Forms.RichControl. On the outside the control looks like a .NET control, while on the inside it's still an ActiveX control. If you have a bit of time, energy, and money invested in COM controls, you can still leverage them in Visual Basic .NET.

To add a reference to a COM control, click the COM tab in the Solution Explorer. The items on the tab are displayed after a few moments, as the registry is searched for all COM items. You can then select the item or items you want and add the reference to your project. If at all possible, however, try to refrain from adding non-.NET components. They are considered unmanaged code because the common language runtime can't handle security or memory management for them. However, you have the option to include them if you need to.

A control object doesn't exist until you actually draw it on a form. When you drop a control from the toolbox onto a form, you are creating an instance of the control class. That particular instance of the control class is the control object you refer to in your application, Button1 in our example. Visual Basic .NET can host only the controls found on the toolbox palette in the IDE. The controls in Visual Basic .NET have been rewritten from the ground up.

Check Out the Code

If you added the code shown earlier that resizes the form and the message box, please delete it now, resize the form to its original size, and then open the code window. It's time to take a closer look at the code generated for us by the Designer.

Double-click the form to bring up the code editor. Much of the code you see will be familiar from Chapter 1. However, take time to let the structure sink in.

Note that the code is sandwiched between the Public Class Form1 and End Class statements. All the code between these statements defines our class. The Form1 class has its constructor, Sub New, so it knows how to create itself. Sub Dispose tells our class how to tear itself down, and Sub InitializeComponent is used by the development environment to persist the property values you set in the Windows Forms Designer. So, when you set a button's Size and Text properties, these values will persist with the form when you quit the project and will be the current values when you start it up again. Our class contains the mechanisms to perform these operations internally, hidden from the prying eyes of the outside world. The subroutine also sets several properties.

Public Class Form1     Inherits System.Windows.Forms.Form #Region " Windows Form Designer generated code "     Public Sub New()         MyBase.New()         'This call is required by the Windows Form Designer         InitializeComponent()         'Add any initialization after the         ' InitializeComponent() call     End Sub     'Form overrides dispose to clean up the component list     Protected Overloads Overrides _     Sub Dispose(ByVal disposing As Boolean)         If disposing Then             If Not (components Is Nothing) Then                 components.Dispose()             End If         End If         MyBase.Dispose(disposing)     End Sub     Friend WithEvents Button1 As System.Windows.Forms.Button     'Required by the Windows Form Designer     Private components As System.ComponentModel.Container     'NOTE: The following procedure is required by the     ' Windows Form Designer.     'It can be modified using the Windows Form Designer.       'Do not modify it using the code editor.     <System.Diagnostics.DebuggerStepThrough()> _     Private Sub InitializeComponent()         Me.Button1 = New System.Windows.Forms.Button()         Me.SuspendLayout()         '         'Button1         '         Me.Button1.Location = New System.Drawing.Point(48, 24)         Me.Button1.Name = "Button1"         Me.Button1.Size = New System.Drawing.Size(184, 48)         Me.Button1.TabIndex = 0         Me.Button1.Text = "&Clone Me!"         '         'Form1         '         Me.AutoScaleBaseSize = New System.Drawing.Size(5, 13)         Me.ClientSize = New System.Drawing.Size(292, 94)         Me.Controls.AddRange(New _             System.Windows.Forms.Control() {Me.Button1})         Me.Name = "Form1"         Me.Text = "Mirror Image"         Me.ResumeLayout(False)     End Sub #End Region     Private Sub Button1_Click(ByVal sender As System.Object, _         ByVal e As System.EventArgs) Handles Button1.Click     End Sub     Private Sub Form1_Load(ByVal sender As System.Object, _         ByVal e As System.EventArgs) Handles MyBase.Load         MessageBox.Show("Form1's height is " & _             Me.Height, Me.Text)     End Sub End Class

The Code Added for the Button

Take a few moments and review the new code. The first item automatically declared for us is a button named Button1.

Friend WithEvents Button1 As System.Windows.Forms.Button

The Button1 object variable will become an instance of the inherited class System.Windows.Forms.Button. When you need to refer to the button object, Button1 is the name you will use.

The keyword Friend is the access modifier. I'll describe access modifiers in more detail later in the chapter. You use various modifiers to manage access to the methods and properties of the objects in your programs. The Friend access modifier makes an element visible to other objects in your component, but not to external objects.

The second keyword, WithEvents, specifies that Button1 is an object variable that can respond to events such as the Click event. Using WithEvents means that your program can include event handler code that responds to events that the button knows about. If you developed your own ActiveX controls or objects in classic Visual Basic, you're no stranger to the WithEvents keyword. It's important to note that the New keyword can't be used to declare object variables that use WithEvents.

To see how smart a button really is, select Button1 in the top left drop-down box in the code editor, which displays all of the objects in the current form. Next click the right drop-down box to display all the events the button knows how to respond to, as shown in Figure 2-6. If you want to have your control respond to any of the built-in events, simply select the event and the IDE will write the event template (or skeleton) for you. It's then up to you to place code in the event procedure to instruct the button how to react when that event occurs.

Locating a Button and a Form

When you move a button control on a form, behind the scenes the IDE keeps track of where you place it. The Location property tells the form where the upper right corner of the button is placed, and the Size property defines how big the button will be.

Me.Button1.Location = New System.Drawing.Point(48, 24) Me.Button1.Name = "Button1" Me.Button1.Size = New System.Drawing.Size(184, 48) Me.Button1.TabIndex = 0 Me.Button1.Text = "&Clone Me!"

The point on the form for the upper left corner of the button, the x and y coordinates of (48, 24), is measured in pixels. Of course, your mileage may vary; in your project these numbers might be different depending on where your button is located on your form.

For every visual component, screen size and resolution can vary depending on your users' systems. Because some operating systems permit you to have multiple monitors attached to a PC, another user's screen or screens might have trouble recognizing the boundaries of the display area, and this confusion can cause your form's location to change unpredictably for the user, in spite of the Location property setting. To manage this situation, the default setting for the StartPosition property for a form is "WindowsDefaultLocation". This setting tells the operating system of the user to compute the best location for the form at startup based on the current hardware. Of course, you could set the StartPosition property to "Center". If you needed the form to be displayed elsewhere, you could modify its location programmatically just after it's displayed.

If you think that your users will have all sorts of Windows configurations, you can use the form's DesktopLocation property to set the location of your form. This property sets the location relative to the taskbar. You might use this property if the user's taskbar has been docked to the top or to the left of the user's screen. Although not very many people do this, docking the taskbar in this way covers the desktop coordinates (0,0) with the toolbar. So if you set your form to appear with a DesktopLocation of (0, 0), it always appears in the upper left corner of the primary monitor. This property will compensate for the taskbar if it is docked at the top. While the DesktopLocation property is set like any other property, it does not show up in the properties box. You can set it only in code. You might write something like the following:

Me.DesktopLocation = new Point (100,100)

Figure 2-6

The list of button events as seen from the IDE.



Coding Techniques for Microsoft Visual Basic. NET
Coding Techniques for Microsoft Visual Basic .NET
ISBN: 0735612544
EAN: 2147483647
Year: 2002
Pages: 123
Authors: John Connell

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net