FoxPro has a command window, which appears automatically when you start up. If the command window isn't visible, you can activate it using Ctrl+F2. The command window is crucial to FoxPro. In it, you can type commands to do virtually everything that you can by clicking on a menu bar. In fact, I use commands so extensively that I've occasionally watched another FoxPro developer do something using the menu and wondered “Why did I never see that before?” Some menu selections actually insert the text of the corresponding command into the command window and execute it there, in effect using the command window as the shell.

The closest equivalent in Visual Basic .NET is Immediate mode in the command window. Although the command window is central to Visual FoxPro, you can use Visual Basic for months without ever opening it. In fact, I haven't opened it up in months. I had to do so just to remember enough to write this paragraph. So, although it's not as central to your work as it is in FoxPro, it can be used in testing and debugging.

Immediate mode in Visual Basic .NET is only available during program execution. You can either set a breakpoint or add Debugger.Break, or press Ctrl+B and specify a breakpoint condition: function name and line number, a variable to monitor for changes, or some other condition.) You can then use the command window (or the Locals window, or one of the four Watch windows) to examine variables. You can use IntelliSense to expose their PEMs (Properties, Events, and Methods). You can execute their methods, run subroutines and functions from the currently executing program, and assign values to object properties.

FoxPro's command window saves prior commands. You can use the UpArrow or PgUp keys to find and execute previously entered commands, or use the keys to cut and paste code into your programs. Visual Basic .NET toggles between Mark and Immediate mode. In Visual Basic .NET's Immediate mode, the up/down arrow keys cycle through recent commands; in Mark mode (which is like the FoxPro variant), you can cut and paste. You can use the shortcuts Ctrl+Alt+I and Ctrl+Shift+M to switch between Mark mode and Immediate mode.

However, Visual Basic .NET doesn't have commands like MODIFY PROJECT, CREATE TABLE, or any of the dozens of commands that you use in FoxPro. Scroll back through your Visual FoxPro command window; every single command you see there will have to be done in Visual Basic .NET either through an IDE menu selection, a builder in one of Visual Basic .NET's windows, an external program (like the Query Analyzer or the SQL Server Enterprise Manager) or through your own program code. As a result, the Visual Basic .NET IDE exposes the equivalents of Visual FoxPro commands, where they exist, as menu selections. That's yet another reason to become very familiar with the .NET IDE before you go too far. (Appendix A, “A Comparison of FoxPro and Visual Basic .NET Commands and Functions,” provides a concordance of Visual FoxPro commands and their Visual Basic counterparts.)

In FoxPro you add controls to your forms using the Form Controls toolbar, which can display either the FoxPro base control classes, your current selection of registered OCXs and DLLs, or any combination of your own class libraries and the excellent classes that ship with FoxPro. Starting with FoxPro 7 you can also drag and drop classes from the Component Gallery. Beginning with FoxPro 8, you have the Toolbox, with tabs for the Component Gallery and a customizable toolbox where you can store your own classes.

The Toolbox is the only way to drag and drop controls onto forms in Visual Basic .NET. In that sense, it replaces FoxPro's Form Controls toolbar. But it does much more. The FoxPro and Visual Basic .NET toolboxes are very similar. Visual FoxPro's Toolbox has bars for text scraps (it's initially seeded with a bug report template and a commented program header, but you can add entries by highlighting and dragging them to the Toolbox). The Visual Basic .NET equivalent is the Clipboard, to which code fragments are automatically added whenever you highlight code or text and press Ctrl+C. Figure 1.1 shows the Visual Basic .NET Toolbox.

Figure 1.1. The Visual Basic .NET Toolbox.

The .NET toolbox contains collections of objects for every conceivable environment: Data, Device Controls, XML Schema, Dialog Editor, Mobile Web Forms, Web Forms, Components, Windows Forms, HTML, the Clipboard Ring, Crystal Reports, and any other toolboxes that you might want to add and customize.

When the Visual FoxPro Screen Designer is open, the Toolbox entries for the FoxPro Base Classes, the Foundation Classes, and My Base Classes permit you to drag and drop screen design elements from the toolbox instead of dragging them from the Form Controls toolbar. Any ActiveX controls that you've registered in the Tools, Options, Controls dialog page will appear here as well, so you don't have to switch between your class library toolbar and the ActiveX Controls toolbar. And you can also use the Form Controls toolbar and the Toolbox at the same time.

In Visual Basic .NET, the Toolbox is your one-stop-shopping source for screen controls and components. As you move from one design context to another, the toolbar elements change to reflect what's appropriate. For example, if you're building an ASP .NET form, you can select from either HTML controls or Web Forms controls. Visual Basic .NET provides a collection of components, such as FileSystemWatcher, MessageQueue, and others that you just don't have in FoxPro.

In Visual Basic .NET, you can build your own user controls, just as you can build your own classes in FoxPro and then add them to the User Controls toolbar. In Chapter 2, “Building Simple Applications in Visual FoxPro and Visual Basic .NET,” you'll learn how to add a Windows Control Library to your project, after which any user controls you add to it will automatically be displayed in the User Controls toolbar. As in FoxPro, you use these controls instead of the standard Visual Basic controls on your forms. And because all of your user controls show up here, regardless of which Windows Control Library they came from, you don't have to switch between VCXs as you do in FoxPro.

Tab ordering of controls is a little different in VB .NET as well. In FoxPro, you can use the Tools, Options, Forms dialog to select either interactive or list ordering of your form controls. If you use interactive ordering, you click on controls in the order in which you want the user to be able to tab through them, then click somewhere on the form surface to tell FoxPro you're done. I usually prefer tab ordering by list.

In Visual Basic .Net, interactive tab ordering is the only way that's available. To start the process, select Tab Ordering from the View menu pad. When you're done, select Tab Ordering from the menu pad again; clicking somewhere on the form won't do a thing.

FoxPro's basic container for building an application is the project. FoxPro stores the pieces of a project in a project file, which is a table and associated memo file with the same structure as a DBF and the extensions PJX and PJT. When the Project Manager screen is open, a Project menu pad with the relevant options (including Set Main, Exclude from Project, and Build Executable/DLL) appears in the FoxPro menu. Although FoxPro has had the ability to build DLLs for several versions, in general FoxPro developers haven't warmed up to them. Files that are located in the current directory are not necessarily listed in the project; files can be listed but excluded, which documents the files' importance to the project. These files remain freestanding elements not included in the executable.

Visual Basic .NET adds one more layer on top of the projects layer: the solution. I think the marketing guys had a hand in this, because where I come from, it's not a solution until it solves something. But I suppose they had to call it something. And I like what it does.

Visual Basic .NET applications sometimes consist of a data server that sends and receives data in XML format, a Windows Forms, and/or an ASP.NET application that uses that data. Because each of these is a project, it's useful to group them in such a manner as to be able to associate the data source with the data consumer. Solutions do just that. If you have only one project, it's still enclosed in a solution. But if there are several related projects, the solution keeps them together for administrative purposes.

Figure 1.2 shows a Visual Basic. NET solution containing a Web service and a Windows form application that uses the Web service. The two FoxPro projects in Figure 1.3 do the same thing, but you just have to remember that they're related to one another. In both cases the Web service and the application that uses it are in different directories.

Figure 1.2. A Visual Basic. NET solution containing a Web service and a Windows form application that uses the Web service.

Figure 1.3. Two FoxPro projects.

However, the solution doesn't produce an executable. Executables or DLLs are the result of compiling projects. Solutions are simply a bookkeeping mechanism. In a solution, there will always be one project designated as the Startup project. That's the one that will run if you press F5. It can't be a class library because they're not executable. But it can be a Web page, a Web service, or any kind of executable.

In FoxPro, although you can compile to APP, DLL, or EXE format, you generally build EXE files. APP files can only be called from another FoxPro application and DLLs require some additional work that generally isn't worth the bother. In Visual Basic .NET (and in earlier versions of Visual Basic), it's common practice to build components as Dynamic Link Libraries (DLLs). Typically, at least one of the projects in the solution compiles to EXE format. DLLs built from other projects in the solution—class libraries, user controls, and the like—are used as components of the executable.

When you build a FoxPro project, you can build an APP, an EXE, a single-threaded DLL, or a multithreaded DLL. APPs can be called by the FoxPro runtime, but I almost always use EXEs. I've only used DLLs for Web services and seldom even then. You can either click on the Build button, press Alt+D, or type BUILD EXE Name FROM Name (BUILD DLL Name FROM Name, or BUILD MTDLL Name FROM Name for multithreaded DLLs).

In Visual Basic .NET, DLLs are used as you might use class libraries in FoxPro. For example, you can build an inheritable form (a Form Template class in FoxPro) as a DLL and inherit from it in another form, after you include the DLL as a reference in your project. When you build a Class Library project in Visual Basic .NET (by right-clicking on the project name in the Solution Explorer, selecting Properties, and setting the Output option to Class Library), the project compiles to a DLL.

When you build a project, the type of project you select determines which references to .NET class library components will be automatically included. You can then add any other references (DLLs or namespaces) that you need. For example, if you want to inherit from an inheritable form that you had built previously, you would add a reference to the inheritable form DLL in your project before trying to add the inherited form. In that way, the project knows where to look for and display any available inheritable forms.

The nearest FoxPro equivalent would be adding class libraries to a project. (The other case where you add references, when you add ActiveX controls to forms, involves using the Tools, Options, Controls page to add ActiveX controls to the Selected list. This causes them to be displayed in the Form Controls toolbar ActiveX menu. However, ActiveX components don't explicitly appear in the Project Manager's file list.)

In Visual Basic .NET you first designate the Startup project because a solution may contain several projects. You can see this if you build my favorite .NET walkthrough, Creating a Distributed Application. (This walkthrough can be found in the Visual Studio .NET, Samples and Walkthroughs Help selection. In it, you build a solution containing a Web service, then add a Windows client application, and finally add a Web client application.) You can designate any of the three as the startup project. If you choose the Web service, a test page is automatically built and presented to you to test those of your Web services that are testable with keyboard input (that is, those that don't have a diffgram [a dataset containing changes made to another dataset] or other type of dataset as the input parameter). Change the Startup Project selection in the Solution Explorer and you can test either of the other projects. It beats fumbling around trying to remember the name of your latest FoxPro Web Service directory.

The code window for a Windows Forms project is shown in Figure 1.4. Unlike FoxPro, which puts each code snippet in a separate window, they're concatenated in Visual Basic. The Text Editor toolbar contains elements for indenting text, setting and jumping to bookmarks, and displaying object and parameter information.

Figure 1.4. The code window for a Windows Forms project.

FoxPro's Document View window automatically displays all of the events and methods in the current form or class where you've already written some code and lets you click to jump to the selected code snippet.

There is no Document View window in the Visual Basic IDE. However, the Class view does just about the same thing, and exposes all of the classes in your project, not just the currently open file. And if you enter comments preceded by a single quote and the word TODO at the beginning of each routine, the Task List (activated from the menu using Alt+V, K, A) will display an entry for each TODO item. Double-clicking on an item takes you straight to the comment line in the code. So with a tiny amount of effort you get the same capability, and in fact, a little more.

To jump to a code snippet that you haven't yet coded in a Visual Basic .NET form, you select the object (for example, the form or a button or list box) from the drop-down list at the upper left of the code window screen, and then select the corresponding event or method from the drop-down list at the upper right of the screen. Just as in FoxPro, the names of snippets containing code appear in boldface. In FoxPro you can open the Properties window and pick the Methods tab, and then double-click on an event or method name to open its code snippet; you can't do that in Visual Basic .NET because events and methods don't appear in the Properties window page. It makes more sense in Visual Basic .NET, but the convenience of FoxPro is nice, too.

Bookmarks and a Task List are both available in both Visual FoxPro and Visual Basic, and perform very similar functions. To create a bookmark in FoxPro, Shift+Double-click or use Alt+Shift+F2. In Visual Basic .NET, use Ctrl+K, which is a toggle. You can also click on the Toggle Bookmark button (the little blue flag) in the Text Editor toolbar. In fact, there are four command buttons in the Text Editor toolbar for managing all aspects of bookmarks; in FoxPro, you have to use the context menu.

In FoxPro, using DBFs is extremely easy. The USE command opens a table. CURSORSETPROP("Buffering",5) turns on optimistic table buffering, so that APPEND BLANK or record changes are not finalized until and unless you issue a TableUpdate() call. TableRevert() undoes anything done since optimistic buffering was enabled. If you're using a DBF, TableUpdate() commits changes back to the file on disk, and you're truly done.

There is no Visual Basic .NET equivalent to FoxPro's DBF in terms of ease of use. You must create a connection to find the data source, a data adapter (or at least a command object) to retrieve the data, and a dataset (an XML schema and container) to hold the data while you work with it. Then you must explicitly send an INSERT or UPDATE command back to the data source. There's even a CommandBuilder object that will use your SELECT command to infer the other three commands for you.

Visual Basic .NET doesn't have a USE command. To connect to a table, you need to define a connection using a connection string such as this one:

Server=(local);Database=Northwind;UID=sa;PWD=;

Visual Basic's Server Explorer exposes some of the capabilities of FoxPro's BROWSE command. After you've defined a connection, you can open a table in the connected database, return all rows, and optionally type changes or additions, which will be sent back to the data source. It allows access not only to ODBC/OLEDB data sources (your FoxPro tables, for example), but also to SQL Server databases.

Thus you can open a database and then view, edit, or add data without opening up the SQL Server Enterprise Manager or the Query Analyzer. You can also create tables, indexes, and relations. Still, the connection to your tables seems a little removed compared to FoxPro. And there's a slight delay when you access any data table. However, you can do all of the things that you can do with FoxPro tables, albeit in more roundabout ways.

In FoxPro, you use CREATE TableName to open up the schema design tool, or MODIFY STRUCTURE to change an existing one. USE TableName opens the table and points to the first row, whereas BROWSE returns the number of rows that you see in the resulting grid. There is no perceptible delay in either a USE or a BROWSE in FoxPro because little or no data is moved from the data source to the workstation.

In FoxPro, we use local tables because they're cheap and because they're fast. In fact, as of this writing, Microsoft doesn't sell a faster data store for single-user workstation applications than FoxPro DBFs with CDX files. (Actually, they don't sell it; they give it away.)

In Visual Basic .NET, using local data sources (like DBFs or Access MDB files) implies exactly the same degree of difficulty as does the use of SQL Server. As a programmer, you save your client no programming costs if you use local tables, as would have been the case with FoxPro.

I would love to have FoxPro's ease of access to local tables in Visual Basic .NET. Still, using the Server Explorer to build connections and data adapters is much easier than it used to be in Visual Basic, so to Visual Basic 6 programmers it's a step up.

In FoxPro you type DO AppName to run an APP, an EXE, or a PRG. You can type DO MAIN.PRG and run your entire application within the IDE, rather than compiling and running an executable with MAIN as the entry point. You can also DO FORM FormName to run a form standalone.

You can't do that in Visual Basic; you can only execute an executable. But it's easy. Press F5 and the designated Startup project runs. To test a form, you'll need to add a couple of lines of code in your main form menu to instantiate the form class as an object and call its Show() method, like this:

Dim Frm as new CustForm
Frm.Show()

That's two lines of code instead of one, but it's almost as easy as DO FORM CustForm.

Both FoxPro and Visual Basic .NET have a class browser. If you need to become familiar with a class in a FoxPro VCX, you can use the Class Browser to examine its structure (although you can't edit the method code in the Class Browser). Also, you'll need to use the Open dialog to locate and open a class. Visual Basic .NET's Class view automatically shows all of the classes in the current solution in a tree view, and permit code editing. To jump to the code for a method, double click on its name.

For your own classes, you use the Class Browser; for all other objects, there's the Object Browser. FoxPro's Object Browser lets you open a type library from any of the registered classes on your computer and browse through the class hierarchy, whereas Visual Basic's Object Browser uses the currently open solution to navigate (although you can browse objects that aren't in the project as well.). It lists the objects of whichever project you click on in the Solution Explorer. Visual Basic .NET's Object Browser not only knows what's in your project, but remembers selected components from session to session. FoxPro's Object Browser is not connected to the current project.

FoxPro's Properties windowopens with Alt+W, P (Windows, Properties), whereas in Visual Studio, F4 brings up the Visual Studio Properties window. You can view properties on .NET's built-in controls, or properties on your own classes.

In both Visual FoxPro and Visual Basic .NET, properties can be listed either alphabetically or grouped by categories. These categories are fixed in FoxPro, whereas in Visual Basic .NET you can add your own by preceding property procedures with the <Category("XYZ")> attribute (provided that you've included Imports System.ComponentModel at the top of your class). Precede your custom categories with an asterisk (for example, *XYZ) and they'll appear right at the top of the Properties window.

The most important difference between the two languages in this regard is that in FoxPro, properties are like public variables of classes and have immediate visibility in the Class Designer as well as in classes that inherit from the class. In Visual Basic you need to write a property procedure (as follows) consisting of about eight lines of code for each and every property that you want to see in the Properties window.

To create a property procedure in a class, you type

Public Property (name)

As soon as you press Enter, the IDE adds six lines of code.

You're expected to do three things:

Furthermore, unlike FoxPro, in Visual Basic .NET you only see your properties in classes that inherit from your class—not in the class itself. So if you define property procedures in a class, you won't see them in the Properties window. As soon as you inherit from that class, the inherited object's Properties window will expose the property.

Property procedures do more than simply expose the property in the Properties window; they also provide a trappable event at the moment of assigning or retrieving a property value. That's what the Get and Set methods (often called Getters and Setters) in a Visual Basic .NET property procedure do. (These will be discussed in more detail in the discussion of the Properties window because they're very important, very different, and you'll use them every day.)

FoxPro properties by default do nothing when you assign them a value, unless you indicate that you want to include Assign and/or Access methods when you add a property in the Class Designer. If you do, FoxPro adds procedures (methods) to the class with the name of the property followed by either _Assign or _Access. You can type code into these methods, and when you either assign a value to the property or request its value, the corresponding property procedure code will execute.

If you're writing classes in a .prg file and you want Assign and Access methods for your properties, simply use the name of the property with _Assign or _Access added to the end of the property name as the procedure name, and it will indeed fire when the property is assigned a value or when the value is read, respectively.

I've only had occasion to use Assign and Access methods twice in my professional career, so I don't think they're very important. Requiring eight lines of code for every single property in a class on the off chance that you might want to use Assign and Access methods seems to me to be a case of the tail wagging the dog. However, you absolutely have to use property procedures if you want to use properties as you do in FoxPro.

The IDE is where you spend your day, so it's important to know where everything is. By this point in your career, you probably don't even need to look for things. When you want to open up the Properties window, your hands type Ctrl+W, P without any conscious effort on your part.

You need to develop the equivalent reflexes for Visual Basic .NET. The task is somewhat complicated by the fact that FoxPro is a command window-based IDE, so that all of the features that are accessible from the menu, or from toolbars, are generally accessible as well by typing a command string.

In both languages, the menus are context-sensitive. For example, the Project menu pad is only visible after you've opened a project. For example, the Form Designer shown in Figure 1.5 must be open in order to right-click on the designer surface and expose the context menu that lets you activate the Properties window.

Figure 1.5. The Form Designer.

Table 1.1 summarizes the menu shortcut or the command that activates the main functionalities of the respective Integrated Development Environments. (The entries in the table assume that the target context is available—for example, the hotkey for a Form Designer feature is only available if the Form Designer is open.)

FoxPro can be managed from the Tools, Options dialog. The Tools, Options page contains a page frame with 14 pages, containing settings that have huge implications for the way the IDE, and your applications, work. Some of these pages have equivalents in Visual Basic .NET, but a few of them don't. For example, the Data and the Remote Data pages, which handle access to DBFs and to SQL using remote views respectively, are irrelevant in Visual Basic .NET; the Data page controls access to DBFs in FoxPro, and in Visual Basic .NET DBFs are just another OLEDB or ODBC data source. Also, the purpose of Remote views in FoxPro is to provide access to SQL Server table data in a way that's very similar to the way we use DBFs.

The Options page I wish Visual Basic .NET had is the Field Mapping page, which controls which of your classes are used to automatically populate a form. There is no equivalent feature in Visual Basic .NET. The Data Form Wizard does some things that are interesting, but I use inheritance for forms, and the wizard doesn't. It's the greatest shortcoming of the form design environment.

Visual Basic .NET also has a Tools, Options menu selection. The resulting dialog uses a tree view for navigation instead of a page frame. In addition, some of the settings found in FoxPro's Tools, Options dialog are to be found in the Solution and Project Properties sheets, respectively. Right-click on either the solution or a project and select Properties from the resulting context menu.

Table 1.2 shows the location of equivalents to the FoxPro Tools, Options Page elements in the .NET IDE.

The FoxPro Task Pane is a command center that brings together resources for learning FoxPro, samples of code, and links to related Web sites. This is similar to the Online Resources panel of the .NET Start Page. Some elements of the Task Pane are to be found in the Tools, Options dialog, under Environment, General (for example, what to show when the IDE starts up). But the FoxPro Task Pane manager doesn't have an exact duplicate in the Visual Basic .NET IDE.

FoxPro's output goes by default to _Screen, the background screen for FoxPro and by default any FoxPro application that you build. You can use a combination of a form's DeskTop, MDIForm, and ShowWindow properties to change that, but many developers use FoxPro's _Screen as their background and as the container for their menu (which replaces FoxPro's _MSYSMENU), as well as for all of the forms in their application. The simple application we'll write in Chapter 2 does just that.

No similar default background exists in Visual Basic .NET. Your first form is the container for all other forms. You manually drop a MainMenu control on the form and use Visual Basic .NET's delicious menu designer, which I would have loved to have in FoxPro.

When an IDE action such as a compile produces output, it opens the Output window by default at the bottom of the screen. If you have compile errors, they'll appear here. You can double-click on an error to be taken directly to the offending code.

In FoxPro, I usually put the form that I'm working on at the upper-left corner of the screen; the Project Manager, Properties window, and the command window over on the right. I reduce the screen resolution to the smallest size that doesn't give me a headache, then expand the Properties sheet to fill almost all of the vertical size of the screen; the Project Manager and the command window split what's left at the lower-right corner of the screen. The Toolbox goes somewhere on top of the properties window whenever I need it.

In Visual Basic .NET I have a more convenient option: I open the Properties window using F4, then open the Solution Explorer with Ctrl+Alt+L and drop it on top of the Properties window. It becomes a member of the same container. I do the same thing with the Toolbox. As I drop these elements, tabs with their names appear at the bottom of the container. All three can thus share in the same space, each coming to the foreground when its tab is clicked.

FoxPro IDE components can be right-clicked and characterized as dockable, which controls whether or not they stay put and behave as expected. I generally make them dockable. Visual Basic .NET components can be configured with more specificity, although I have a 21-inch monitor and it's still not big enough. If the truth be told, though, it's not big enough for FoxPro application development either.

Getting used to the IDE is important if you want to enjoy application development. And it's a never-ending task. I even learned a bunch of new IDE tweaks from Cathy Pountney at the DevTeach Conference in Montreal, and I've been doing this for 15 years. Productivity is the name of the game, and the fine folks in Redmond have given us some great tools. So take the time to learn where things are in the IDE and what they can do for you. It's a small investment that will return a big dividend.

Intermediate language is the result of the compilation project in Visual Studio .NET, regardless of which language you use to write the code. It looks a bit like assembler. When you first run an executable on a workstation, the internal IL is compiled to machine codeas pieces of your application are invoked. This happens each time the application is run, and a noticeable delay occurs during compilation.

The FoxPro IDE does something similar. If you DO a PRG inside FoxPro and if an .fxp file exists with an earlier time stamp, FoxPro automatically compiles the PRG to produce an FXP. If the FXP is more recent, it's run, and the PRG is ignored. Of course, we don't send PRGs to our customers, and the FoxPro runtime can't compile them; but the analogy is useful.

In general, project elements are either code or data. If they contain code, their extension indicates which language you chose for your project (currently .vb, .cs, or .js for Visual Basic, C#, and J#). There are also a host of extensions that have been created for various components of a Visual Studio solution or project component. Generally, these are tables in XML format. In FoxPro we use DBFs with other extensions; the notion is precisely the same.

Some files have companion files under certain circumstances. For example, forms have a .resx (resource) file, which contains information about the form. Open it up, and you'll be able to see the contents either as XML or in table form.

Similarly, .xsd (schema) files have an associated .vb or .cs file if they represent a typed dataset. Typed datasets allow FoxPro developers to do something near and dear to our hearts—use the Table.Field syntax in Visual Basic .NET that we have always had in FoxPro. To do so in Visual Basic .NET, there must be a class with one property procedure for each field name in the table in question. These classes are automatically generated by the Generate Dataset phase of the DataAdapter Wizard dialog.

If you generate a typed dataset (an XML schema file with an .xsd extension), the .xsd file will have a .vb file behind it with one property procedure for each column in the table. You have to click the Show All Files button to see it. Typed datasets are the only way you'll be able to type employee.lastname in Visual Basic .NET. You don't even want to know what you have to type to refer to a field without them. I imagine that FoxPro does something similar internally, although not knowing about it has never bothered me.

Other files in the project use XML files to store tables of information concerning how to manage and build the project. An XML file in its simplest form describes rows and columns, so it's exactly like a DBF without the ability to have an index and thus be searched quickly. You can think of them as dumbed-down DBFs. Generally, if you double-click on a file with a .vbproj, .sln, .xsd, or other extension, you'll get XML; and at the lower-left corner of the screen you'll see a Data tab. Click on it to see a tabular representation of the XML.

A solution can consist of multiple projects. Typically, one of them is an executable, and the rest are class libraries, which are compiled into Dynamic Link Libraries (DLLs).

There is a fundamental belief in the non-FoxPro world that components should be bullet-proofed, then shared as DLLs and patched together. What would be a class library in FoxPro is generally built as a separate DLL in Visual Basic, and shared with other developers. FoxPro developers generally view their class libraries as an integral part of the forms that use them, and continue to modify forms and the class libraries that use them simultaneously. Because sharing DLLs is a normal practice in the non-FoxPro developer communities, they're often looked at as a final product, and subjected to quality assurance procedures of some sort.

That's not the world of the rapid prototyper, the world we as database developers live in. My clients' requirements shift daily, sometimes hourly. I simply can't send out a memo requesting changes in a DLL, and then wait a few weeks for them to code, test, and ship back the result for me to test.

In FoxPro, although you can do this, I've never felt the need to build components and stitch them together to build the executable. It just never occurred to me—and still doesn't, come to think of it. I don't see changing our thinking to accept black-box DLLs as a normal component of application development in FoxPro. But in Visual Basic .NET, classes compile to DLLs—there is no equivalent to FoxPro's VCX file.

FoxPro uses a current directory concept. At any time you can type CD in the command window to see “where you are”—that is, what the current directory is. You can also type ? SET("DEFAULT") or ? CURDIR() to display the current directory in the output window (_Screen). You can use CD (path) or SET DEFAULT TO (path) to change it. Before creating a project, you use CD and MD commands to create and navigate to the folder the project will occupy.

The mere fact that files are located in this directory doesn't make them part of the project, and in fact a project isn't strictly necessary. FoxPro is unique in that you can run programs without compiling them. If you type DO MAIN in the command window, the program will run exactly as if you had compiled it and run the executable. And even if you do build an executable, if FoxPro can't find a program, screen, menu, or class file in the executable, it searches first in the current directory, and then along any paths specified with a SET PATH TO command (for example, SET PATH TO Classes;Menus;Programs).

If you type CREATE Table1, a dialog opens to allow you to build a table schema and store it in a file with a .dbf extension (and optionally an additional file with the same name and the extension .fpt if your table schema contains variable-length fields called “memo fields”). Any DBF that has variable-length fields has an associated memo file with the extension "FPT". There are other extensions that are used for other types of files. I'll introduce each of them.

Projects are stored in one of these file pairs with the extensions .pjx and .pjt respectively. The "PJX" is the "DBF" file, and the "PJT" is the "FPT" file. It shouldn't surprise you that FoxPro uses a table to store the project details. Screens, classes, and reports use the same scheme of pairs of files with extensions that suggest their usage.

Visual Studio uses HTML files for similar purposes. For example, each page in an ASP.NET application is stored in an HTML file with the extension "aspx", which is essentially a table containing the descriptive elements of the page. The code is stored separately in a “code-behind” file. But if you change the page, you don't have to recompile, because it's just data—exactly as if it were coming from a DBF.

By default, any files you create for a project will go in the current directory. When you create a project using the MODIFY PROJECT Name command, the .pjx and .pjt files are created. Subsequently, as you add other files like MAIN.PRG, they are put by default into the current directory.

If you build a menu, an MNX/MNT file pair is created. If it's included in a project, in the project record for the MNX file an MPR file with the same filename and the extension .mpr is designated as the outfile. The compiled code for the resulting compiled MPX file is stored in the Object memo field.

If you create a form (screen), a pair of files with .scx and .sct extensions are added. Again, if there's no project, FoxPro will compile and run the SCX file using the DO FORM FormName command. The SCX/SCT files don't have to be part of a project.

If you create a class library, a VCX/VCT pair is created. It has exactly the same column layout as an SCX/SCT file pair. (Think about that for a while. This is the reason that you can select Save As Class in the Form Designer and then instantiate a form object from the saved form class using frm = CREATEOBJECT("formclassname") followed by frm.Show()—almost exactly the same syntax used in Visual Basic .NET.)

If you use a FoxPro project file, when you build the application, any included PRG files are compiled, and the generated FXP code is added into the corresponding MAIN.PRG record in the object memo field. If you called an MPR (menu) program, it is compiled into an MPX file and the MPX is included in the executable. Any SCX (screen) and VCX (class) files are compiled and added to the executable.

After the source files have been compiled, you don't need to ship any of them to your users; the executable contains everything. However, if there's no project, FoxPro will look for and execute the MPX file if it exists; if not, it will look for and compile the MPR file, and then run the resulting MPX file. It won't automatically build an MPR file from an MNX file, though; you have to do that in the Menu Builder, or let the Project Manager do it for you at build time.

Similarly, any referenced screen files are called as needed. Class library files, on the other hand, whether in VCX or as DEFINE CLASS statements located in PRG files, must be referred to in the code with SET CLASSLIB TO VCXFileName ADDITIVE and SET PROCEDURE TO PrgFileName ADDITIVE in order for FoxPro to know how to use their contents.

Reports are stored in FRX/FRT pairs. It's common practice to exclude report files from the project and then simply build a list of available FRX files for the user to select. In this way, customized reporting is easy to support.

Unlike Visual FoxPro, Visual Basic puts your project in the directory you name when you create the project. By default the project directories you create are created under a default projects folder, which you can and should change when you start using Visual Studio.

For each project, .NET creates a project folder using the project name you supply, within your default projects folder. It also automatically creates a solution (with the extension .sln) with the same name as the project. A solution is a grouping of related items such as a form and the routine that returns data to it, or a Web page and a Web service. There can be any number of projects in a solution, but only one of them is the startup project that runs if you press F5.

FoxPro doesn't have this additional layer. I wish it did. I have to write down which Web service goes with which applications on little sticky notes. A little bookkeeping help would be nice.

Whereas FoxPro uses tables to store projects, screens, menus, and classes, Visual Basic uses either .vb files or XML text files to store solution details.

If you're fond of customizing your projects in FoxPro using Ctrl+J, you'll be interested to know that you can right-click on the solution and select Properties to set a number of characteristics of the solution. Similarly, you can right-click on a project and select Properties from the resulting context menu to set project properties. However, if you want to set the program's name, the company's name, versioning information and so forth, double-click on the AssemblyInfo.vb file in the project and fill in the Assembly attributes you'll find there.

To call a procedure called ProcName in FoxPro, you either type DO ProcName or simply ProcName(). The parentheses are required. The second variant is the way you call a subroutine or function in Visual Basic .NET.

If you instantiate an object named MyObj that has a method called ProcName, you call it using MyObj.ProcName. If it has parameters, you can add parentheses after the name and put the parameters within them. Otherwise, the parentheses are not required.

In Visual Basic .NET the syntax is exactly the same, except that DO ProcName() is not supported.

The well-known Canadian developer Steven Black has pointed out in several articles that string handling in FoxPro is thousands of times faster than it is in Visual Basic 6. In Visual Basic .NET, the String module contains dozens of methods that are more efficient. Type the word “String” and a period in a code window, and Intellisense will show you what's available.

In addition to the string functions found in FoxPro, String.Format can be used like TextMerge:

FoxPro:
 Name = "Fred" 
 Age = 32
 SET TEXTMERGE ON NOSHOW
 TEXT TO X
 <<Name>> is <<TRANSFORM(age)>> years old.
 ENDTEXT
 ? X

VB:
 Dim Name As String = "Fred"
 Dim Age As Integer = 32
 Label1.Text = String.Format("{0} is {1} years old", Name, Age)

In FoxPro, RETURN takes you out of the current procedure, THISFORM.Release closes the current form, and QUIT ends the program. RETURN from the MAIN program also ends the application, unless you're running MAIN from inside the FoxPro IDE. So a compiled application can use RETURN to end the program.

In Visual Basic .NET, CLOSE() closes a form; End ends the program. You can't end a program with Return in Visual Basic.

In FoxPro, DO...ENDDO is used to do something repetitively until a condition is satisfied. In the following FoxPro example, we test a printer object, and if its ErrorOccurred property is set to .T., or if its PrintedOk property is set to True, we exit the loop; otherwise, we keep trying.

DO WHILE .T.
   oPrinter.Test
   IF oPrinter.ErrorOccurred or oPrinter.PrintedOk
      EXIT
   ENDIF
ENDDO

DO WHILE is not as frequently used as its cousin FOR ... ENDFOR or FOR...NEXT. The syntax is either

FOR I = 1 TO N
   - do something -
ENDFOR | NEXT

or

FOR EACH obj IN Collection
   - do something -
ENDFOR | NEXT

Finally, in FoxPro, where we have tables and cursors, there is a special command pair to traverse the table or cursor from top to bottom:

SCAN
   - do something -
ENDSCAN

The Visual Basic equivalent is to use a FOR EACH row IN table loop:

Dim dr as datarow
For each dr in dataset.tables(0)
... 
End For

In Visual Basic .NET, the equivalent of FOR...NEXT is very similar:

FOR I = 1 TO N
   - do something -
NEXT I

However, DO...LOOP has four variants. The first two check the expression at the beginning of the loop, whereas the last two check the expression at the end of the first loop:

If that isn't enough, there's a While...Wend construct that's similar to DO...LOOP, except that it doesn't support Exit:

While condition
   statements
Wend

In Visual FoxPro you can use either of these two mechanisms to execute only a certain block of code:

IF Expr
   - Execute if true -
ELSE
   - Execute if not true -
ENDIF

or

DO CASE
   CASE Expr1
   - Execute if Expr1 is true -
   CASE Expr2
   - Execute if Expr2 is true -
ENDCASE

It's a peculiarity of FoxPro's DO CASE construct that the expressions evaluated in the CASE statements don't have to refer to the same variable. It's very flexible.

As usual, Visual Basic .NET has more constructs. I don't know if that's good or bad: Sometimes although we're offered several ways of doing things, one of them is really the preferred method.

Choose returns the numbered entry from a list of choices, for example:

Return Choose(idx, "Lions", "Tigers", "Bears")

Choose is a primitive construct from years ago, and will seldom if ever be the best choice. It has been deprecated.

If Salary > 1000000.00 Then
   Bonus =  1000000.00
 Else
   Bonus = 25.00
End If

If Salary > 1000000 Then Bonus = 1000000
If Salary > 1000000 Then Bonus = 1000000 Else Bonus = 25
If Salary > 10000 Then Salary = Salary * 2 : Bonus = 10000 
Else Salary = Salary / 2: Bonus = 25

Select case StateName
       Case "CA"
            Governor = "Arnold"
       Case Else
            Governor = "Someone else"
End Select

Return Microsoft.VisualBasic.Switch( _
 CityName = "London", "English", _
 CityName = "Rome", "Italian", _
 CityName = "Paris", "French")

Data type declarations in FoxPro take two forms: fields in tables and memory variable creation. Scope declarations can be used to declare data types in FoxPro, for example:

LOCAL Salary as Double

In addition, function and procedure declarations can describe parameter types and return value types. However, it's an illusion; FoxPro data is stored internally as variants, and typing is not enforced. For example, the following Visual FoxPro function will cheerfully concatenate a pair of strings passed to it as parameters:

FUNCTION Test (One as Integer, two as String) as String
RETURN TRANSFORM( one, "@L ###") + Two

And the following code runs fine in FoxPro:

LOCAL MyVar AS Integer
MyVar = "Oops!"

In FoxPro, although there are 14 possible choices for a field type in a table, for in-memory data representation there are only six types: Character, Currency, Numeric, Date, DateTime, and Logical. Finer data resolution only happens when you store the data to a table. Visual Basic's insistence on converting to many more data types doesn't matter in FoxPro. The TYPE and VARTYPE functions report back objects as type “O”.

Table 1.5 compares the data types available in Visual Basic to the FoxPro data types and to FoxPro DBF Field types.

In Visual FoxPro, some confusion results from the fact that PUBLIC, PRIVATE, and LOCAL refer to variable scope, whereas PROTECTED and HIDDEN refer to property and method visibility, and PROTECTED will always be part of a FUNCTION or PROCEDURE declaration in a class definition; no confusion there. But PUBLIC can refer to either a variable or to a property or method of a class.

PUBLIC, PRIVATE, and LOCAL are declarations that precede variables and determine their scope. If a variable is declared in a program, by default it's visible in that routine and in any routine below it. For example, if MAIN contains a line like Name=[Les] and uses DO FORM CUSTOMERS to show a form, within the form you can type THISFORM.Caption = [Les] in the form's LOAD event and the form's caption will appear as “Les”. If you move the line Name=[Les] to the CUSTOMERS form and change the Load code to read

Name=[Les]
THISFORM.Caption = Name

the form's caption will change, but as soon as the form closes, the variable Name disappears. Technically, it is said to go out of scope.

LOCAL means that a variable exists only within the procedure in which it's named, whereas PRIVATE means that it exists in the procedure in which it's created as well as in any procedure called by that procedure.

For example, variables can be scoped before a value is assigned using a PUBLIC, PRIVATE, or LOCAL declaration:

PUBLIC Address        && will be available after exiting this procedure
Address = FileToStr ( ClientAddressTextFile )

LOCAL I
FOR I = 1 TO 2        && does not conflict with any global instance of I
    ? "Hi"
ENDFOR

Within a program, we declare variables to store values. The declaration of and use of variables in Visual Basic looks confusing to FoxPro developers because it requires an extra step that's optional in FoxPro. And the reason for it is that in Visual Basic, all variables are actually objects.

In FoxPro, you declare a variable by assigning it a value:

X = 3

Similarly, you declare a class property by assigning it a value:

DEFINE CLASS Person AS Custom
FirstName = []
LastName = []
ENDDEFINE

FoxPro generally declares all variables as variants, which means you can assign any value to them. In fact, you can change their data type in the middle of the program—usually inadvertently and with confusing results. It's not a good idea, but it's possible. However, you can declare types using the PUBLIC, PRIVATE, and LOCAL declarations:

LOCAL LastName AS String
PUBLIC I AS Integer

You can also declare objects based on classes in your class libraries, or from the FoxPro base classes:

LOCAL oDoc as Word.Document
oDoc = CREATEOBJECT ( "Word.Document")

However, all variables declared with the LOCAL, PUBLIC, or PRIVATE declarations have an initial value of .F., and can be changed to any other data type any time you want. So why bother?

Type declarations in FoxPro are used to permit specification of parameters for creating Dynamic Link Libraries (DLLs), which require a type library (TLB) entry that specifies parameter data types in a universally accepted format. Because FoxPro didn't have anything but variants, type declarations were added to the language to permit building Web services, which must specify their parameters and output types. But internally, they're pretty much ignored except for supporting IntelliSense.

Similarly, classes can have PRIVATE and PUBLIC properties and methods. IntelliSense reveals the public ones, whereas private ones are not visible.

Essentially, PUBLIC variables are accessible any time after being declared, as if they had been initialized in the MAIN program. PRIVATE variables are declared in the procedure in which they are created and in procedures called by the creating procedure. LOCAL variables are available only within the creating procedure, so they're perfect for loop counters. In general, the idea is to avoid inadvertently overwriting a variable. That's the story on variable declarations in FoxPro. Pretty simple, isn't it?

Visual Basic .NET is rendered more confusing because there are scope declarations for functions and procedures as well as for variables. We'll look at these in great detail shortly.

In Visual Basic, variables are objects. In fact, you can't use variables unless you first declare them with a statement that specifies which object they're derived from. Best practices dictate that you use Option Strict On and Option Implicit Off, so that the compiler will stop you from trying to assign an integer to a string variable. This can catch a certain type of programmer error that can be hard to diagnose.

This is the reason that many functions in FoxPro are methods of objects in Visual Basic. For example, in Visual FoxPro you use the UPPER(StringVar) function to convert a string to uppercase. In Visual Basic .NET, strings are objects, with dozens of built-in methods. The string object's methods include a ToUpper method. So the Visual Basic .NET equivalent of UPPER(StringVar) is StringVar.ToUpper. In a way it's better: Type a string variable's name, press the period key, and IntelliSense shows you all of the object's methods. In FoxPro, you'd be searching Help about now.

Variables are created from the named type using the DIM statement, which has the following syntax:

[ <attrlist> ] [{ Public | Protected | Friend | Protected Friend |
                  Private | Static }] [ Shared ] [ Shadows ] [ ReadOnly ]
                  Dim [ WithEvents ] name[ (boundlist) ] 
                      [ As [ New ] type ] [ = initexpr ]

If any of the first nine declaratives are used, Dim can be omitted. An explanation of each of these options follows:

Any of these attributes can be used with the DIM statement to allocate memory for variables. DIM comes from DIMENSION, which was the only way to allocate memory for variables in the early version of BASIC and was never replaced by ALLOC as it should have been. The DIM keyword is optional if any of these others are used, so it's often left out. If only DIM is used, it defaults to Private. That's part of the source of the confusion. Just think of Public, Protected, and so on as alternate ways of saying Dim. If you want to use variables in classes as we use them in FoxPro, you can generally use Public or Friend. Inside a procedure, just use Dim.

There are three variations on variables that demonstrate important differences between Visual FoxPro and Visual Basic .NET. We'll look at them here.

MsgBox ("Hi",

If MsgBox(
   "Print", _
     MsgBoxStyle.Question _
 and MsgBoxStyle.YesNo _
 and MsgBoxStyle.DefaultButton1) _
   = MsgBoxStyle.Yes

If MessageBox ( "Print", 4 + 32 + 256 ) = 6

Enum SecurityLevel
   IllegalEntry = -1
   MinimumSecurity = 0
   MaximumSecurity = 1
End Enum

Dim x() as String  ' the array will be dimensioned by the mechanism that creates it

Dim x(5) as Integer ' the array will have six elements, to be filled in later

DIMENSION X(1)
X(1) = "Hi there"
DIMENSION X(4)

X = CREATEOBJECT("Collection")
x.Add(_Screen,"one") 

WAIT WINDOW x("one").Caption

X("one").WindowState = 1

We can't leave the subject of variables without discussing table fields. In FoxPro, if you USE (TableName), or if you SELECT (TableName) subsequently, you expose the fields of the table as if they were memory variables. In fact, if you issue the SCATTER MEMVAR command, FoxPro creates duplicate memvars for all of your fields. How can you distinguish them?

Just remember that the field is the default. If both exist, the current table's field is assumed to be what you want, unless you preface the memvar with "m.". It's actually a common hard-to-find bug. The best fix for this is to preface the field name with its table name and a period, for example, Customers.Address, and to preface memvars with "m.". Alternatively, you can preface all memvars with an additional m. It seems like overkill, but FoxPro developers are used to it.

Visual Basic .NET doesn't have fields. Well, it does, but field in Visual Basic .NET means what we'd call a local variable in a class in FoxPro. But as you'll see, typed datasets act pretty much like FoxPro tables do in this regard. A typed dataset is a Visual Basic program, usually (make that always) generated by a program, that adds one property procedure for each field in a table. That is, when you create a dataset (an .xsd file, which is actually an XML file), if you ask the wizard to create a typed dataset, it will generate the code for you.

There are third-party tools available that will do this job for you, and I suspect that Whidbey (the next version of Visual Basic .NET) will do so as well. RapTier from SharpPower.com builds a robust data tier. Visible Developer and DeKlarit do even more. All of these are better than typing these things in yourself, or using the one that's automatically generated by the IDE.

Typed datasets allow you to do data binding using a syntax that looks just like FoxPro's; for example, you fill in tablename.fieldname in the DataBindings - Text property (the equivalent of the FoxPro controlsource property). However, data binding goes only as far as the dataset, which is a local cursor. It doesn't write the data back to the source table, wherever that is. For that you need a command object, as you'll see shortly.

But even the many variations on declaring variables discussed in the preceding section don't cause as much confusion as subroutine and function declarations. For one thing, functions and subroutines in FoxPro have always been a bit amorphous; either one can return or not return a value.

Visual Basic .NET is very particular about this. Functions must return a value, and it must be of the type specified in the RETURN statement. To make matters worse, someone in Redmond (and I think I know who it was) once decided that assigning the function's value to its name was a good way to hide the RETURN statement, or save a line of code, or who knows what. So you see code like this:

FUNCTION DollarsToCharacters (inputval as double) AS String
DollarsToCharacters = CSTR(inputval,10,2)
END FUNCTION

SET PROCEDURE TO <filename> ADDITIVE

FUNCTION DollarsToCharacters
PARAMETERS InputVal
RETURN STR(InputVal,10,2)
ENDFUNC

FUNCTION DollarsToCharacters ( InputVal as Numeric ) AS String
RETURN STR(InputVal,10,2)
ENDFUNC

[ <attrlist> ] [{ Overloads | Overrides | Overridable | 
NotOverridable | MustOverride | Shadows | Shared }] 
[{ Public | Protected | Friend | Protected Friend | Private }] 
Sub name [(arglist)] [ Implements interface.definedname ]
   [ statements ]
   [ Exit Sub ]
   [ statements ]
End Sub

[ <attrlist> ] [{ Overloads | Overrides | Overridable | 
NotOverridable | MustOverride | Shadows | Shared }] 
[{ Public | Protected | Friend | Protected Friend | Private }] 
Function name[(arglist)] [ As type ] [ Implements interface.definedname ]
   [ statements ]
   [ Exit Function ]
   [ statements ]
End Function

Dim da as New SQLDataAdapter("SELECT * FROM Customers", "server=(local);database=NorthWind, PWD=sa;")

Dim cn as New SQLConnection("server=(local);database=NorthWind, PWD=sa;")
Cn.Open()
Dim da as New SQLDataAdapter("SELECT * FROM Customers", cn)

MyBase.New()

Public Class Class1

    Public Interface Foo
        Property Banana() As String
        Sub One(ByVal a As String)
        Function Two(ByVal b As String) As String
    End Interface

End Class

Public Class Class2
    Implements Class1.Foo
    Public Property Banana() As String Implements Class1.Foo.Banana
        Get

        End Get
        Set(ByVal Value As String)

        End Set
    End Property

    Public Sub One(ByVal a As String) Implements Class1.Foo.One

    End Sub

    Public Function Two(ByVal b As String) As String Implements Class1.Foo.Two

    End Function

End Class

The following summary of function scope declarations describes the available options. After I describe them, I'll suggest a simple approach.

One thing that will come up constantly in .NET is the creation and use of objects based on .NET classes. For example, the following code opens a table and displays its contents in a datagrid (the .NET equivalent of FoxPro's BROWSE):

Dim cn As New SqlConnection("Server=(local);Database=Northwind;UID=sa;PWD=;")
cn.Open()
Dim da As New SqlDataAdapter("SELECT * FROM CUSTOMERS", cn)
Dim ds As New DataSet
da.Fill(ds)
DataGrid1.DataSource = ds.Tables(0)

The statement Dim cn As SQLConnection is like FoxPro

LOCAL cn As String

It doesn't create the variable. It just announces your intention to do so at some future date. Sounds goofy, but it's true. (It actually feeds IntelliSense - in both cases.) It's supposed to be followed by the statement that actually creates the variable. It can either be done with a New statement, or by referring to a member of an existing object. If you leave out the word New in the Dim cn statement above, you won't be able to pass the connection string in as a parameter. In the fourth line of the same code, you can leave out the word New without incurring a syntax error, but the following line will bomb because Fill only works with an existing Dataset, and the statement Dim ds As Dataset doesn't create one – it only declares one.

For years, Visual Basic developers got used to the idea of trapping the assignment of a value to a property and doing something when that assignment occurred. For example, I used to use a communication package that used the following syntax to read data from a telephone line:

OModem.Setting = 14
OModem.Action = 4    ' Read

The way this worked was that the moment of assigning a value to a property was trapped in what is called the Property Set method. At that instant, other code can be called. So they used that when they couldn't declare a “Do-it” method. It was a workaround for Visual Basic's inability to give us any way to simply write oModem.Read. After a while, the workaround seemed normal. Goofy but true.

The tradition continues. If you type

PUBLIC PROPERTY FullName AS String

and press Enter, Visual Basic will add complete the routine by adding the following six lines of code:

Public Property FullName() As String
    Get

    End Get
    Set(ByVal Value As String)

    End Set
End Property

You have to add three more lines of code, one before the routine and two within it, to end up with this:

Private _FullName As String
Public Property FullName() As String
    Get
       Return _FullName
    End Get
    Set(ByVal Value As String)
       _FullName = Value
    End Set

If you have two properties, you'll have two of these. If you have 20 properties, you'll have 20. Notice that a separate private variable (by convention the name is the property procedure's name preceded by an underscore) is required in order to store the value manipulated by the property procedure, and it must be declared outside of the property procedure.

This is the equivalent of the Assign and Access methods that FoxPro allows you to create when you add a property to a class. As you may know, you can add code to the Assign method code to do other tasks when the property is assigned a value. That's the idea behind property procedures.

However, in Visual FoxPro property procedures (that is, Assign and Access methods) are completely optional; I've only had occasion to use them twice in years of client development.

In Visual Basic .NET, you can't see either class properties or public class variables in the Properties sheet for the class. However, you can't see public class variables in the Properties sheet. And you can only see them in subclasses that inherit from your classes. That's right; to get what you call a property in FoxPro, you must create a public property procedure in Visual Basic .NET. Strange but true. So even if you don't need the Assign and Access methods (called Getters and Setters in Visual Basic), you need property procedures. The fact that Visual Basic writes most of the code diminishes the pain, but I think it's goofy, and hope that it will be replaced by FoxPro's much simpler and clearly adequate counterpart some day.

Forms are classes in Visual Basic .NET. If you refer to one in a menu, it will take either two or three lines of code to display the form:

Dim frm as new CustomerForm    ' can be written as 2 lines of code
Frm.Show

In FoxPro you just write

Do form Customer

However, have you ever looked at the structure of an SCX file? It has exactly the same structure as a VCX file. And in fact, if you save a form as a class, the code to run the form changes to this:

Frm = CREATEOBJECT ( "FormClassName", "VCXFILE.VCX" )
Frm.Show()

So they're more similar than you might have thought.

Forms have a section of code called the “Windows Form Designer generated code.” When you're in the form designer, things that you do, like adding controls on the form, moving things around, and assigning values to properties, are actually stored in source code. The designer merely uses this code to create a visual display of the code's contents. If you manually change this code, it will be overwritten whenever a change is made in the designer and the file is saved.

However, sometimes it's useful to write code that is saved as part of the form's initialization sequence – for example, using property values to open tables and populate some standard controls. If you have such code, you can place it in the Public Sub New() method, after the word InitializeComponent(). It's the only place in the Form Designer generated code that you can include code that won't be overwritten by the designer.

FoxPro's classes have properties, events, and methods. Properties are variables, and methods are functions and procedures. But you can't add events. When you subclass a base class, you can add properties and methods at will. You can also add your own code to the existing methods. For example, when you refresh a form, you can add code to SEEK() records in all related tables so that bound fields displayed on the form will be coordinated.

Events are different. Events happen. When they do, any code that you add to the event's code window is executed, in addition to the default behavior of the event. But events happen when they happen—when you click, or double-click, or mouse over, or whatever. You don't add events in FoxPro.

Each of FoxPro's base classes comes with a generous but fixed list of events. You can't add to FoxPro's events; you're stuck with the list of events that each class was born with. In FoxPro, the name of an event implies what it handles. TextBox1.Click tells you which object the Click event responds to. There is no Handles clause at the end. It's not needed. You don't even see the mechanism that handles it. It's transparent.

To add code for an event, you pick the event from the Method Name/Members combo box of the code window navigation bar (at the upper-right side of the screen).

FoxPro's IDE supplies any necessary parameters. The code, in the form of an LPARAMETERS statement, is inserted when the code window opens. If you erase the LPARAMETERS line and leave the code window empty, the LPARAMETERS line will be put back in the next time you open the code window. For example, open a new MouseDown event code window and you get this:

LPARAMETERS nButton, nShift, nXCoord, nYCoord

There is no Event statement in FoxPro. (There are three new functions [BindEvent, RaiseEvent and ReleaseEvents] related to events in Visual FoxPro8, but it's difficult to come up with a reason to use them.) Looking at the list of events for a typical FoxPro control, I can't imagine why I'd want to add more events. That's why the Event statement in Visual Basic has always confused me. And why “raise” an event? Aren't events things that just happen, like “Click”?

This is at the heart of the reason that FoxPro developers can't easily understand Visual Basic events. The events that are declared for the purpose of calling them with RaiseEvent have nothing to do with the events that come with controls. That's not what RaiseEvent is used for in Visual Basic.

One of the really huge differences between FoxPro and Visual Basic .NET is Visual Basic's use of events. FoxPro objects have events, and you can write code in the event snippets that will run when the event fires. It's transparent. In Visual Basic, event handling is not transparent. You get to watch.

If you create a Windows Form project and add a text box to the form, you'll find the following generated code in the form's codebehind:

    Friend WithEvents TextBox1 As System.Windows.Forms.TextBox
...
    'TextBox1
    '
    Me.TextBox1.Location = New System.Drawing.Point(110, 54)
    Me.TextBox1.Name = "TextBox1"
    Me.TextBox1.TabIndex = 0
    Me.TextBox1.Text = "TextBox1"
    Me.Controls.Add(Me.TextBox1)

If the WithEvents clause were not included, the program would ignore any of the control's events. Presumably, doing so causes the program to run faster; otherwise, why would the WithEvents clause exist? This allows us to add a Handles clause to a subroutine, regardless of its name, that “reacts” when the named event occurs. So what is the Visual Basic default—without events? Oddly enough, it is.

The IDE writes the code for you if you open the code window and select an object from the Objects drop-down list at the upper-left corner of the window, and then select an event from the drop-down list at the upper-right corner of the same window.

For example, the following code changes the text box back to black text on a white background when the cursor leaves the control:

Private Sub TextBox1_LostFocus( _
       ByVal sender As Object, _
       ByVal e As System.EventArgs) _
      Handles TextBox1.LostFocus
    TextBox1.ForeColor = Color.Black
    TextBox1.BackColor = Color.White
End Sub

Although a subroutine name that references the event name is generated when you add the code, the name is in fact functionally unrelated to what the routine does. You can change the name, and the program will work exactly the same. The Handles clause at the end is what causes the subroutine to execute when the event fires. Or, as they like to say in Redmond, when the event is raised.

The two parameters in parentheses that follow the subroutine name are always ByVal sender As Object (a reference to the calling object) and an event argument whose type is based on what kind of parameters the called event needs. For example, if you add a MouseDown event routine, you get the following code:

Private Sub Form1_MouseDown( _
  ByVal sender As Object, _
  ByVal e As System.Windows.Forms.MouseEventArgs) _
 Handles MyBase.MouseDown
 Debugger.Break   ' like SET STEP ON
End Sub

I've included a breakpoint so that you can type “e” into the Watch window and see what it is. It's a structure containing the values needed to respond to a mousedown event: X and Y coordinates, among others. So it's pretty much the same thing that FoxPro is doing with its generated LPARAMETERS statements. One more mystery solved.

If this were the only use for events in Visual Basic .NET, you could simply ignore them and let the IDE generate event-related code whenever it felt like it. The developers of FoxPro apparently felt that the confusion resulting from optionally exposing events in this way was not worth the bother. Generally, they were correct.

Events in Visual Basic are also used as a workaround for a characteristic of the Visual Basic compiler that prevents it from calling functions and procedures that aren't resolved at compile time. In particular, although you can instantiate an object based on a class and call the object's methods at will from within a form, you can't do the opposite in Visual Basic. For example, in FoxPro, you can't call THISFORM.Refresh from inside a class, like this:

DEFINE CLASS Utilities AS CUSTOM

PROCEDURE CoordinateTables
THISFORM.Refresh        && in whatever form is active
ENDPROC

ENDDEFINE

You can, however, use _Screen.ActiveForm.CoordinateTables. You can even use PEMSTATUS ( Object, MethodName, 5 ) to determine whether the method exists before calling it. So we have workarounds in FoxPro. But in Visual Basic they don't. (Well, there is reflection, but it's new. RaiseEvents has been around since Visual Basic4 at least, so that's how they do it.)

In Visual Basic you can't call a method in a form from inside an object without resorting to some trick. RaiseEvent is that trick. That's why it's so confusing. Here we are trying to think up events that might go beyond clicking or double-clicking. The use of RaiseEvent is a trick with mirrors to overcome a limitation in the compile process for Visual Basic. You don't need to try to invent events in FoxPro. There's no reason to. You can do what you need to do without them. In Visual Basic, you can't.

This is why FoxPro developers have a hard time understanding events in Visual Basic. All of FoxPro's events are always trappable; there is no need to use WithEvents to declare that the events for a control are subject to handling; they just are. And the second reason for using events in Visual Basic is unnecessary in Visual FoxPro!

In Visual Basic, Public Sub XXX Handles ObjectName.EventName can be used to respond to the line RaiseEvent EventName in a class. So a form can contain a subroutine that is called when the event named in the Handles clause of the subroutine fires (or is raised, as they like to say).

To declare an event in a class, include the statement

Public Event <Name> ( Parameters )

Instantiate your object:

Dim oObj as New <ClassName>

Then, within the code, invoke it using the RaiseEvent command:

RaiseEvent <Name> ( Parameters )

This “raises” the event and passes any parameters to it. Finally, trap the event using the Handles clause of a subroutine in the form:

Public sub xxx ( Parameters as string ) Handles oObj.EventName

Using this mechanism, I've created a “hook” that lets me call any method in the form when something happens in the class. Note that I could simply call a method in the class using oObj.MethodName ( Parameters ), as I do in the Update button code in Listing 1.5. But if I want to call form methods from the class, this is actually a pretty clean way to do it.

Here's an example, based on the “Visual Basic .NET How-To N-Tier Data Form App” sample included in the “101 Visual Basic .NET Samples” library available for free from the MSDN site. I can't say enough about this code library, which gives you good examples of how to do a huge variety of things in Visual Basic .NET. I've added a few properties so that it's more flexible and easier to configure.

Option Strict On
Imports System.Data.SqlClient

Namespace DataAccessLayer

Public Class DataAccess

    Protected Const CONNECTION_ERROR_MSG As String = "Couldn't connect to SQL"
    Protected Const SQL_CONNECTION_STRING As String = _
                    "server=(local);database=Northwind;uid=sa;pwd=;"

    Public da As SqlDataAdapter
    Public ds As DataSet

    Public _MainTable As String
    Public _KeyField As String

    Protected DidPreviouslyConnect As Boolean = False
    Protected strConn As String = SQL_CONNECTION_STRING

    Public Event ConnectionStatusChange(ByVal status As String)
    Public Event ConnectionFailure(ByVal reason As String)
    Public Event ConnectionCompleted(ByVal success As Boolean)

    Public Property MainTable() As String
        Get
            Return _MainTable
        End Get
        Set(ByVal Value As String)
            _MainTable = Value
        End Set
    End Property

    Public Property KeyField() As String
        Get
            Return _KeyField
        End Get
        Set(ByVal Value As String)
            _KeyField = Value
        End Set
    End Property

    Public Function CreateDataSet() As DataSet

        Dim ds As DataSet
        If Not DidPreviouslyConnect Then
            RaiseEvent ConnectionStatusChange("Connecting to SQL Server")
        End If
        Dim IsConnecting As Boolean = True
        While IsConnecting
            Try
                Dim scnnNW As New SqlConnection(strConn)
                Dim strSQL As String = "SELECT * FROM " + MainTable
                Dim scmd As New SqlCommand(strSQL, scnnNW)
                da = New SqlDataAdapter(scmd)
                Dim cb As New SqlCommandBuilder(da)
                ds = New DataSet
                da.Fill(ds, MainTable)
                IsConnecting = False
                DidPreviouslyConnect = True
            Catch exp As Exception
                If strConn = SQL_CONNECTION_STRING Then
                    RaiseEvent ConnectionFailure(CONNECTION_ERROR_MSG)
                End If
            End Try
        End While
        RaiseEvent ConnectionCompleted(True)
        da.Fill(ds, MainTable)
        Return ds

    End Function

    Public Sub UpdateDataSet(ByVal inDS As DataSet)
        If inDS Is Nothing Then
            Exit Sub
        End If
        Try
            If (da Is Nothing) Then
                CreateDataSet()
            End If
            inDS.EnforceConstraints = False
            da.Update(inDS, MainTable)
        Catch exc As Exception
            RaiseEvent ConnectionFailure("Unable to update the data source.")
        End Try
    End Sub

End Class
End Namespace

The form code answers the question “What do I do when these events occur?” The Data Access Layer class is instantiated as object m_DAL. The events are referred to with the prefix m_DAL because they belong to the object. See Listing 1.6.

Option Strict On
Imports System.Data.SqlClient
Imports DataAccessLayer

Public Class frmMain
    Inherits System.Windows.Forms.Form

...Windows Form Designer generated code goes here...

    Protected DidPreviouslyConnect As Boolean = False
    Private ds As DataSet
    Private dt As DataTable
    Private dv As DataView

    Public MainTable As String = "Customers"
    Public KeyField As String = "CustomerID"

    Protected WithEvents m_DAL As DataAccess

    Dim frmStatusMessage As New frmStatus

    Private Sub btnNext_Click( _
      ByVal sender As System.Object, _
      ByVal e As System.EventArgs) _
     Handles btnNext.Click
        NextRecord()
    End Sub

    Private Sub btnPrevious_Click( _
      ByVal sender As System.Object, _
      ByVal e As System.EventArgs) _
     Handles btnPrevious.Click
        PreviousRecord()
    End Sub

    Private Sub btnRefresh_Click( _
      ByVal sender As System.Object, _
      ByVal e As System.EventArgs) _
     Handles btnRefresh.Click
        frmMain_Load(Me, New System.EventArgs)
    End Sub

' Call the UpdateDataSet method:
    Private Sub btnUpdate_Click( _
      ByVal sender As System.Object, _
      ByVal e As System.EventArgs) _
     Handles btnUpdate.Click
     m_DAL.UpdateDataSet(ds.GetChanges())
        frmMain_Load(Me, New System.EventArgs)
    End Sub

    Protected Sub dt_PositionChanged( _
      ByVal sender As Object, _
      ByVal e As System.EventArgs)
        BindGrid()
    End Sub

    Private Sub frmMain_KeyDown( _
      ByVal sender As Object, ByVal e _
      As System.Windows.Forms.KeyEventArgs) _
     Handles MyBase.KeyDown
        If e.KeyCode = Keys.Right Then NextRecord()
        If e.KeyCode = Keys.Left Then PreviousRecord()
    End Sub

    Private Sub frmMain_Load( _
      ByVal sender As Object, _
      ByVal e As System.EventArgs) _
     Handles MyBase.Load
        frmStatusMessage = New frmStatus
        GetDataSet()
        BindGrid()
    End Sub

    Private Sub grd_CurrentCellChanged( _
      ByVal sender As Object, _
      ByVal e As System.EventArgs) _
     Handles grd.CurrentCellChanged
        grd.Select(grd.CurrentCell.RowNumber)
        If TypeOf (grd.Item(grd.CurrentRowIndex, 2)) Is DBNull Then
            grd.Item(grd.CurrentRowIndex, 2) = _
                grd.Item(grd.CurrentRowIndex, 0)
        End If
    End Sub

    Private Sub grdClick( _
      ByVal sender As System.Object, _
      ByVal e As System.EventArgs) _
     Handles grd.Click
        BindGrid()
    End Sub

* Handle the ConnectionCompleted event:
    Private Sub m_DAL_ConnectionCompleted( _
      ByVal success As Boolean) _
     Handles m_DAL.ConnectionCompleted
        frmStatusMessage.Close()
    End Sub

* Handle the ConnectionFailure event:
    Private Sub m_DAL_ConnectionFailure( _
      ByVal reason As String) _
     Handles m_DAL.ConnectionFailure
        MsgBox(reason, MsgBoxStyle.Critical, Me.Text)
        End
    End Sub

* Handle the ConnectionStatusChanged event:
    Private Sub m_DAL_ConnectionStatusChange( _
      ByVal status As String) _
     Handles m_DAL.ConnectionStatusChange
        frmStatusMessage.Show(status)
    End Sub

    Sub BindGrid()
        With grd
            .CaptionText = MainTable
            .DataSource = dv
        End With
    End Sub

    Sub GetDataSet()
        frmStatusMessage.Show("Retrieving Data From Data Access Layer")
        ds = m_DAL.CreateDataSet()
        dt = ds.Tables(MainTable)
        dv = dt.DefaultView
    End Sub

    Public Sub NextRecord()
        grd.UnSelect(grd.CurrentRowIndex)
        grd.CurrentRowIndex += 1
        grd.Select(grd.CurrentRowIndex)
    End Sub

    Public Sub PreviousRecord()
        grd.UnSelect(grd.CurrentRowIndex)
        If grd.CurrentRowIndex > 0 Then
            grd.CurrentRowIndex -= 1
        End If
        grd.Select(grd.CurrentRowIndex)
    End Sub

End Class

frmStatus is just a simple form with a label control in the center of the screen and an override of the form's Show method code:

Public Overloads Sub Show(ByVal Message As String)
    lblStatus.Text = Message
    Me.Show()
    System.Threading.Thread.CurrentThread.Sleep(500)
    Application.DoEvents()
End Sub

This displays the form with a message and resumes execution after a half-second delay.

To summarize: If you want to use events in your classes to call methods in forms when you don't yet know which form and which methods, do this:

The syntax for TRY...CATCH is slightly different for Visual Basic .NET than for Visual FoxPro.

Here's the syntax in Visual FoxPro:

TRY
      Code here
Catch To oEx WHEN ERROR() = 1234
      What to do for this error
Catch To oEx WHEN ERROR() = 4321
      What to do for this error
Catch To oEx
      What to do for all other errors
Finally
      Do this whether there was an error or not
ENDTRY

At a minimum, you can print out the error details:

Msg = oEx.Message + CHR(13)+oEx.Details + CHR(13)+oEx.LineContents
MessageBox ( Msg, 32, "Error" )

And this is the syntax in Visual Basic .NET:

Try
      Code here
Catch oEx as ExceptionType1  (of about 60 exception types)
      Code to handle ExceptionType1
Catch oEx as ExceptionType2  (of about 60 exception types)
      Code to handle ExceptionType2
Catch oEx as Exception
      Code to handle all other Exceptions
Finally
      Do this under all circumstances
END Try

Similarly, you can print out oEx.Message + CHR(13)+oEx.Source to see the error message and offending code.

Visual Basic does have additional language elements (Error, Raise, GetException, Err, On Error, and Resume), but Try...Catch is a lot better.

Error trapping is meant to allow graceful handling of unavoidable errors in the program, due to device unavailability (CD-ROM, printers, floppy drives), incorrect input that can't be prevented, and other errors that are the result of normal program operation. Error trapping is not meant to be used to catch errors in program logic. Still, it's better than letting users see messages from the FoxPro or the .NET IDE.

In the code that appears in this book, we have left out error trapping in most code samples. That doesn't mean that we recommend leaving it out of your code. In fact, Try...Catch blocks are an excellent idea, and should be used in every case where a user or system error is possible. (It can even be helpful in finding your own coding errors during debugging, although that's not the purpose of Try...Catch.) But we've decided to focus on the main purpose of each code fragment, and adding error trapping to a single line of code tends to make the code harder to read. So with regard to error trapping, do as I say, not as I do.

Debugging support is awesome in both languages. In FoxPro, you can either toggle a breakpoint by clicking in the selection margin of the code at the point where you want the code to break, or you can insert a SET STEP ON command. In Visual Basic .NET, you can either toggle a breakpoint by clicking in the selection margin of the code at the point where you want the code to break, or you can insert a Debugger.Break command.

At this point FoxPro provides you with five windows:

In addition, you can add assertions to your code. Assertions are statements that only execute if they evaluate to False, and only if you SET ASSERTS ON. You'll get a little dialog window that asks if you want to debug. This permits bracketing of debugging code in a way that it can be turned on and off with a single command in the command window.

In Visual Basic .NET, Debugger.Break (or a breakpoint entered in the Selection Margin of the code window) gives you a vast array of debugging windows:

Each of these windows gives you some of the information about your program's state at the breakpoint. You can either go to the command window in Immediate mode and print the contents of individual Variables and object properties, type the name of the object in a watch window, or look in the Locals window to see if it's there already.

It's clear that both languages offer excellent error trapping and debugging capabilities.