A Whole New World

When I first began to look at Visual Basic .NET a couple of years ago, it reminded me of the movie Alien . Nothing looked familiar!

Where's the command window? And when you find it, what is it for? In Visual FoxPro, you can practically dispense with the menu and just type commands in order to do your work. For example, instead of selecting File, Open , Project from the menu, you can type MODIFY PROJECT (or MODI PROJ as most FoxPro commands can be abbreviated to four characters ) and the project name , or just let the list of matching files pop up and press the spacebar to pick the first one. In Visual Basic, although there is a command window, the list of commands that you can type is pretty short.

And while I'm at it, where have all the functions gone? Recent versions of FoxPro (and of Visual Basic, for that matter) have around two thousand commands and functions. Visual Basic .NET has only a couple of hundred. Where did they go?

In FoxPro, commands and functions are in many cases simply wrappers for calls to DLLs that are themselves components of Windows. The developers of FoxPro enclosed all such method calls in wrappers to produce the commands and functions that you see when you enter HELP . For example, the UPPER function converts a string to uppercase. In Visual Basic .NET, the Upper method belongs to string objects. So UPPER(mVar) in FoxPro is mVar.Upper in Visual Basic.NET.

Other methods belong to classes, such as Strings and Math. Thanks to IntelliSense, you can type "Strings." Or "Math.", and when you press the period, in each case several dozen familiar method names will appear. But you have to know in which class to look. In FoxPro, you're relieved of the responsibility of knowing which Dynamic Link Library (DLL) the method came from.

Most methods are only exposed when you instantiate an object based on a particular class. For example, TableUpdate() in FoxPro is like a dataset's AcceptChanges() method. But to get to the point where you can use it, you would have to create a dataset, which requires creating a new connection, opening it, creating a new dataadapter, using its Fill method to create a dataset, displaying the dataset in a table to allow the user to make changes, then executing the dataset's AcceptChanges() method to save the changes, like this:

 Imports System.Data.SQLClient Public ds as Dataset Dim cn as New SQLConnection("server=localhost;database=North Wind;UID=sa;PWD=;" Cn.open() Dim da as New SQLDataAdapter("SELECT * FROM Customers",cn) ds = New DataAdapter Da.fill(ds) DataGrid1.DataSource = ds.Tables(0) ... ' Save commandbutton Click event handler: Ds.AcceptChanges() ...  ' Code to save changes back to data store 

That would be two lines of code in FoxPro:

 BROWSE TableUpdate(.T.) 

One of the characteristics of the .NET languages that looks strangest to Visual FoxPro (VFP) developers is that most of what were commands and functions in FoxPro are methods of some two hundred class libraries (called namespaces in .NET) containing over two thousand classes. If you want to use a method, you instantiate an object based on the class that contains it. Then when you type the object's name and a period, IntelliSense kicks in, and the entire list of properties, events, and methods is laid out before you like a banquet table. In order to get to this point, however, you have to know which of the approximately two thousand classes contains the method you want. In some sense, you have to know what you're looking for in order to find it.

Some classes are directly accessible, without requiring that you first instantiate an object based on them. For example, type "Strings.", and as soon as you type the period, a list of dozens of familiar functions appears, again thanks to IntelliSense. Similarly, typing "Math." Displays most of the math functions you know and love in FoxPro. So as long as you know to start by typing the name of the Namespace that contains the functions you need, they're only a word away.

FoxPro FUNCTION and PROCEDURE declarations are as simple as can be. In Visual Basic .NET, Sub and Function declarations seemed to include keywords of endless variety: Overrideable , Shadow , Protected , MustOverride ”what did these mean? And did I really have to know about all of them and use all of them in my code? And variable declarations in Visual Basic .NET have a different but equally perplexing variety of options. Do I need to use some of these options? All of them?

And what's up with events? The handling of events in Visual Basic escaped me for years. My eyes glazed over every time I saw the word WithEvents . How was it possible that Visual Basic relied so completely on a feature that you don't even have in FoxPro? You can do everything that events are used for in Visual Basic .NET transparently in FoxPro, without any special effort. I spent hours trying to think of a reason to create an event that FoxPro didn't already have so that I'd have a reason to "raise" it.

I also discovered that data binding, one of FoxPro's greatest strengths, is Visual Basic .NET's greatest weakness. Data binding is so intrinsic in Visual FoxPro that you don't even think about it (at least not until you change to a different data store than the DBF). In .NET, data access is disconnected; there are always additional steps required ”sometimes lots of them ”to send edited data back where it came from.

After months of experimentation, I finally concluded that most of the things I do in FoxPro are done in very similar ways in Visual Basic .NET. Little by little I've found equivalences that make me feel more at home. And sometimes, I even find something in Visual Basic that I like more than the analog in FoxPro. Other than minor name changes, there are only a few things that are truly different.

In most cases, you can ignore many of the powerful but irrelevant features in Visual Basic .NET and use only a subset that's just right for database development. In saying this, I know that I run the risk of incurring the territorial wrath of some guy who's just written an article about how critically important it is to use overloading in all of your applications ”because if I'm right, he's just wasted your time and a tree. (There's a lot of money to be made by saying that things are harder than they really are, because if you're a consultant, and if you know about it and they don't and if they really, really need it, they had better hire you.) But I'm not afraid of controversy, as you may know. Someone has to point out that the emperor's naked.

Before you start building applications, let's review the principal differences between Visual FoxPro and Visual Basic .NET. I've summarized these differences in this chapter under 12 major subject headings. After reviewing these differences, you should be able to read Visual Basic .NET code and have a general idea of what the code is trying to do.