C# ПІДРУЧНИКИ / c# / Hungry Minds - ASP.NET Bible VB.NET & C#

MenuCheck("Open Address")

'Set the Parent Form of the Child window.

frmAdd1.MdiParent = Me

frmAdd1.Show()

Build the application before you run it this time, because a lot of changes have occurred in different areas of the solution. If all goes well, when you run the program, you should see the splash screen followed by the MDI main form. Then, open the address window to see the subroutine being called. If you have successfully written this project, the debug window should appear as shown in Figure B-4.

Figure B-4: Debug window showing results of the MenuCheck subroutine

Now, every time your system users select that menu item, the message will go to the debug window. Of course, this example is not the most practical of all examples, but it should have at least brought the point home that some subroutines or functions can be used in a generic way, and in a way that is independent of the overall application solution.

Built-in Functions

This section looks at some of the built-in functions that are provided with .NET. This product is so vast that it would almost take an entire book just to cover all the built-in functions that are provided. So, the scope here will certainly be much more narrow. The point of this section is to provide a general introduction to these tools and to help you become comfortable enough using some of them that you are confident enough to explore and discover more of the provided functions when the need arises in your applications.

A built-in function, as its name suggests, is a function that is built into the .NET compiler and that always performs the same task. You, as an application developer, generally cannot change or alter the actions of a function that is provided with .NET, but you have this plethora of tools at your disposal whenever you need them. These functions come in many different categories, and, as mentioned before, you will only be shown a few of the more common ones at this time, namely some of the data conversion functions.

Data conversion functions

One of the most common tasks a program needs to do is to convert data between variables of different data types. For example, suppose you are handling data from an external source over which you have no control regarding the format in which it provides

Built-in Objects

Just as .NET has many built-in functions, it also has many built-in objects. Once again, a few definitions will be helpful before we get into the meat of built-in objects:

§Object: A programming entity that can have both state (known as properties) and actions (known as methods) associated with it. A real-world example of an object would be a rubber ball. A .NET example of an object would be a clickable push button on a window form.

§Property: Something that an object owns or that describes its characteristics in such a way that it can be uniquely identified within its object. Taking the rubber ball as an example of an object, one of its properties would be its color. Taking the .NET example of an object, a push button on a form, a property of that push button would be its text label, typically OK or Cancel.

§Method: An action that can occur that affects an object. In the example of the ball, an action that can be performed against it is to roll it. An example here could be the printing action of a window or form.

As you can see from the preceding code example and Figure B-5, a .NET solution involves a lot of object manipulation. After you become more familiar with the coding style of the .NET environment, you will notice that most of the code is either calling functions (built-in or handmade) or subroutines and manipulating an object's properties or methods. There are variations of course and you will also find that your code will be doing a fair amount of employing variables to hold temporary data, but you will come to see that the code is usually focused in one of these main veins.

Brief Tour of the Debugger

This section completes the overall tour of the VB.NET product. So far in Appendix A and Appendix B, you have looked at the IDE of VB.NET and have written a fair amount of code. The code has dealt a lot with variables, functions, and objects at varying levels. If you look back over the previous pages, you will see that a lot of information was covered and that you have actually learned quite a lot about the product and how to manage it.

But soon you will begin to write applications to suit your own needs. You have the basic skills to get by, but what happens when you hit that first wall? You have checked all of your code and the logic looks good, yet when you launch your application, it performs sporadically. Where do you go for help? What can be done to rectify a wayward application? Enter the debugger!

The application debugger is a tool that ships with the VB.NET product and is set up for your use as soon as you install it. Debugging code involves two major levels: compiletime debugging and run-time debugging. These are discussed next.

Using the compiler

Compile-time debugging occurs on two smaller levels of its own. One level is the simple debugging of code that you perform when you are writing the application code. You know just by reading through it that it is not likely to work as you want it, or that you have noticed a design flaw in your code during its writing, so you make the needed adjustments. You have also used the second aspect of this first line of defense against badly performing code, and that is the compiler's build feature. When you select Build → Build in the .NET environment, you are instructing the compiler to look through your code and inform you of any glaring programming mistakes. If you have a successful build, then the Output window will display a message similar to that shown in Figure B-6.

Figure B-6: Successful build results in the Output window

The IDE code editor helps you out with flagging any compiler issues as well by highlighting any erroneous code as you write it. For example, if you leave out the End Sub command when defining a subroutine, the code editor will either suggest a solution to you or flag the code as problematic. But when you actually invoke the build process, you are telling the compiler to take another complete pass through your whole application, to look for any programming errors. If the build process passes, then you are ready to run the application. If, however, you are presented with a report showing some errors, you may not be able to run your application at all (depending on the severity of the error).

Using the debugger

After you actually have finished the building and scanning of your code and are ready to run the application, you may still be faced with some bugs that are more of a challenge to ferret out. This is where the run-time debugger becomes very helpful. As you can see in Figure B-7, few options are presented to you on the Debug menu before the solution is actually executed. The debugger is invoked in either of two ways. One is to select Debug → Start (or pressing F5). The second way is to place a break point in the code close to where you suspect the bug to be. Setting of break points is discussed a bit later.

Figure B-7: Debug menu items

Note To jump between the debugging session and the running application, simply use the Windows task bar to switch between any running applications.

Stepping into and over

The Debug menu has a few options that you will want to learn to use (as well as their corresponding hot keys). The first menu item that you should become familiar with is Debug → Step Into (which also can be invoked by pressing F11 after the debugger is active). This menu item will run each line of code for you in a step-by-step process. It enables you to look at the state of the running application in many different ways. For example, if you are tracking down a programming error and want to examine the code and the actions of the application as it runs, you can use this option (after the debugger is running) to step into each line of code. Another neat feature of this option is that if a function or subroutine is about to be called in a subsequent line of code, you can press F11 to step down into that function so that you can follow the application as it travels from function to function.

If, however, you know that a certain function is bug free, you can use the other most common Debug menu item, Debug → Step Over. The code in the function that you want to step ove r is still executed, but the debugger does not take the time to show you each line of code in that function as it executes.

Figure B-8 shows you a debugging session of the MenuCheck subroutine that was created earlier in this appendix (refer to the section, "Defining functions and scope"). During the debug session, the Write function also ran, the output of which is shown in the little window at the bottom right. In addition, a watch [Watch?] variable was set, instructing the debugger to specifically watch and report on the state of the frmAdd1 object. As shown in the bottom-left window of Figure B-8, the debugger reported that the frmAdd1 object has not been declared.

Figure B-8: Debugging session showing the current line of code with a watch variable set

Setting break points

Setting a break point is one of the best features to use in a debugging session. This feature stops the processing of the program code at a location specified by the programmer. This enables you to run your application through all the working parts and to stop just before the area where a bug may be happening. Then, after the code is stopped and displayed to you, you can use the F11 and F10 hot keys to fine-tune the bug hunt.

To set a break point, simply open the code in question in the code editor and click the mouse button on the empty gray bar to the left of the line of code that you want to break on. This invokes the break point holder, shown in Figure B-9. The line of code is highlighted in red and a large red dot appears in the gray band on the left.

Figure B-9: Debug window showing set break point

This was, as promised, a very brief tour of the VB.NET debugger. Many aspects of it were not covered here. You are encouraged to take some time to explore this application troubleshooting tool and see what else it can do for you.

Summary

This appendix has shown you how to create your own functions and subroutines, and how to use and invoke a built-in function. You have been introduced to the basic object-

oriented concepts of methods and properties. You have also been shown how to use the VB.NET debugger.

Appendix C: Visual Basic Object-Oriented

Programming

Overview

VB.NET is based on the concept of object-oriented programming (OOP). Therefore, it is essential to understand the meaning of OOP and how it is used in VB.NET. While the concept of OOP remains the same for most programming languages, its usage with regard to VB.NET has a slight difference.

In versions prior to VB 4.0, forms, controls, and databases were nothing but objects. Logically speaking, the next question that should come to mind is what in the world are "objects" and why are the variables that you declare not categorized as objects. Basically, it would be correct to state that any version of VB before VB 4.0 was not object oriented — in spite of the fact that while programming with VB, you are actually using objects. This might sound funny and ambiguous, but when you complete reading the contents of this appendix, you will have a thorough understanding of the concepts of OOP.

In addition, you will also learn the concept of classes and how they are created. Finally, you will learn how to create an object hierarchy by using the concept of inheritance. These concepts have a logical link amongst themselves, which is why these concepts are covered one after another.

Introduction to Object-Oriented Programming

To begin understanding the concept of object-oriented programming with respect to VB.NET, it is essential to understand OOP in the generic sense. A generic definition of OOP would be something along the lines of, "A collection of independent objects, which represent instances of a class and can be bound by the relationship of inheritance." To have a clearer understanding of this definition, let's split it into three parts:

§A collection of objects: This suggests that object-oriented programs use objects. Objects are the logical building blocks of a program.

§Represented by an instance of a class: This part of the definition suggests

that an object is an instance of a class.

§Bound by the relationship of inheritance: This part of the definition suggests that the classes can be bound together and have a relationship. This relationship is nothing but inheritance.

An object-oriented program is one that is capable of satisfying each of these three conditions. If even one of the conditions is not applicable to a programming language, it cannot be considered an OOP language. Programming languages that do not use inheritance should consciously not be categorized as object-oriented languages. To understand the concept of OOP, you need to understand classes and objects.

Classes and objects

While working in VB.NET, you would have already worked with classes and objects, though you never knew it. The question that arises now is how to create your own classes and their objects. Just observe the toolbox that you use to put controls on your form. All the controls present on the toolbox actually represent classes, and you create an object of these classes by dragging and dropping a control on the form. You can now define an object as an instance of a class. A class defines the fields, properties,

methods, and events of an object. If you take the example of birds as a class, then the objects that will fall under it will be peacock, sparrow, and kingfisher. An object can also be defined as an independent unit that consists of data and methods that are used to manipulate this data.

You can create multiple objects (instances) of a class. All of these objects share the same set of characteristics, such as properties, methods, and events that are provided by the class. However, the property values for each object might be different. For example, you can create multiple buttons on your form. By doing so, you are creating multiple instances of the Button class. All the buttons have similar sets of properties, such as Name and Text, which are defined in the Button class. However, you will specify a different name for each button.

You create an object of a class by using the Dim statement. For example:

Dim emp As Employee

The preceding statement creates an object named emp of the Employee class. You need to use the New keyword to assign memory to this object. For doing so, consider the following statement:

Dim emp As New Employee

Properties

Objects, in Visual Basic, have certain attributes that describe them. These attributes are nothing but properties. Just as credibility, goodwill, and size are attributes that describe an organization, properties describe objects.

You can set or retrieve values from these properties as you do with variables. For doing so, first you need to access the property and then assign the value. To access the property of an object, you use the following syntax:

Object.Property

In the preceding syntax, Object refers to the name of the object and Property refers to the name of the property that is to be accessed.

The following syntax explains assigning or retrieving values from a property:

Object.Property = value

Result = Object.Property

Consider the following example that returns the value stored in a text box and then assigns a new value to the text box:

'Declare a string variable

Dim strName As String

'Retrieve the value stored

StrName = txtName.Text

'Assign a new value

txtName.Text = "John"

In this code sample, txtName is an object of class TextBox.

Methods

Objects perform tasks on the data they contain. The tasks that are performed on the data are undertaken by procedures and functions that are specified in the class definition. In OOP, these procedures and functions are called methods. You can access the methods of an object like you access the properties.

For example: