Programming VB.NET - A Guide For Experienced Programmers

Peter Kitson

ISBN : 1893115992

Order a printed copy of this book from Amazon.

For your free electronic copy of this book please verify the numbers below. 

(We need to do this to make sure you're a person and not a malicious script)

What does all of this have to do with .NET? Quite a lot. You see, .NET is going to change the way you design your applications as much as the introduction of classes to VB changed the best way to build your VB5 or 6 applications. And just as we VB programmers suffered through the change from the classless to classenabled incarnations of VB, so will we feel some pain in the transition to .NET! With that in mind, let us look at some of the things to watch out for—or take advantage of—when switching from VB6 to VB .NET.

The Common Language Runtime

Visual Basic has always used a runtime, so it may seem strange to say that the biggest change to VB that comes with .NET is the change to a Common Language Runtime (CLR) shared by all .NET languages. The reason is that while on the surface the CLR is a runtime library just like the C Runtime library, MSVCRTXX.DLL, or the VB Runtime library, MSVBVMXX.DLL, it is much larger and has greater functionality. Because of its richness, writing programs that take full advantage of the CLR often seems like you are writing for a whole new operating system API.5

Since all languages that are .NET-compliant use the same CLR, there is no need for a language-specific runtime. What is more, code that is CLR can be written in any language and still be used equally well by all .NET CLR-compliant languages. Your VB code can be used by C# programmers and vice versa with no extra work. Next, there is a common file format for .NET executable code, called Microsoft Intermediate Language (MSIL, or just IL). MSIL is a semicompiled language that gets compiled into native code by the .NET runtime at execution time. This is a vast extension of what existed in all versions of VB prior to version 5. VB apps used to be compiled to p-code (or pseudo code, a machine language for a hypothetical machine), which was an intermediate representation of the final executable code. The various VB runtime engines, interpreted the p-code when a user ran the program. People always complained that VB was too slow because of this,7 and therefore, constantly begged Microsoft to add native compilation to VB. This happened starting in version 5, when you had a choice of p-code (small) or native code (bigger but presumably faster). The key point is that .NET languages combine the best features of a p-code language with the best features of compiled languages. By having all languages write to MSIL, a kind of p-code, and then compile the resulting MSIL to native code, it makes it relatively easy to have cross-language compatibility. But by ultimately generating native code you still get good performance.

The object-oriented features in VB5 and VB6 were (to be polite) somewhat limited. One key issue was that these versions of VB could not automatically initialize the data inside a class when creating an instance of a class. This led to classes being created in an indeterminate (potentially buggy) state and required the programmer to exercise extra care when using objects. To resolve this, VB .NET adds an important feature called parameterized constructors (see Chapter 4).

Another problem was the lack of true inheritance. (We cover inheritance in Chapter 5.8) Inheritance is a form of code reuse where you use certain objects that are really more specialized versions of existing objects. Inheritance is thus the perfect tool when building something like a better textbox based on an existing textbox. In VB5 and 6 you did not have inheritance, so you had to rely on a fairly cumbersome wizard to help make the process of building a better textbox tolerable.

As another example of when inheritance should be used is if you want to build a special-purpose collection class. In VB5 or 6, if you wanted to build one that held only strings, you had to add a private instance field that you used for the delegation process:

Private mCollection As Collection \'for delegation

Then you had to have Initialize and Terminate events to set up and reclaim the memory used for the private collection to which you delegated the work. Next, you needed to write the delegation code for the various members of the specialized collection that you wanted to expose to the outside world. For example:

Sub Add(Item As String)

mCollection.Add Item

End Sub

This code shows delegation at work; we delegated the Add method to the private collection that we used as an instance field. The sticky part came when you wanted a For-Each. To do this you had to add the following code to the class module:

Public Function NewEnum As IUnknown

Set NewEnum = mCollection.[_NewEnum]

End Function

and then you needed to set the Procedure ID for this code to be –4! (Obviously, "and then magic happens" is not a great way to code. With inheritance, none of this nonsense is necessary.) In VB .NET you just say

Class MyCollection

Inherits Collection

and you get a For Each for free (see Chapter 5).

Programmers who used Visual Basic always had a problem with memory leaks from what are called circular references. (A circular reference is when you have object A referring to object B and object B referring to object A.) Assuming this kind of code was not there for a reason, there was no way for the VB compiler to realize that this circularity was not significant. This meant that the memory for these two objects was never reclaimed. The garbage collection feature built into the .NET CLR eliminates this problem of circular references using much smarter algorithms to determine when circular references can be "cut" and the memory reclaimed. Of course, this extra power comes at a cost, and Chapter 4 will explain the advantages and disadvantages of automatic garbage collection.

All versions of Visual Basic use a form of error handling that dates back to the first Basic written almost 40 years ago. To be charitable, it had problems. To be uncharitable (but we feel realistic), it is absurd to use On Error GoTo with all the spaghetti code problems that ensue in a modern programming language. Visual Basic adds structured exception handling (see Chapter 7) the most modern and most powerful means of handling errors.

Multithreaded programs seem to do two things at once. E-mail programs that let you read old e-mail while downloading new e-mail are good examples. Users expect such apps, but you could not write them very easily in earlier versions of VB. In Chapter 10 we introduce you to the pleasures and pitfalls of this incredibly powerful feature of VB .NET.