The Integrated Development Environment (IDE)

Visual Basic .NET is similar to the latest version of FoxPro. Features like the Visual FoxPro 8 Toolbox and the Task Pane appear to have been ported directly from .NET. As you'll see, many of the differences stem from the fact that Visual Basic .NET can build many kinds of applications ” Windows Forms, ASP.NET Web pages, Web Services, Smart Devices (Pocket PC and Tablet PC applications), console applications, services that run when your computer starts up, and others. Visual FoxPro only builds two (executables and DLLs).

FoxPro can create .app and .exe files as well as .dll s. However, the .app and .exe files contain tokenized FoxPro, not machine code. The .app files can only be called by other FoxPro programs. The .exe files are .app files with a loader that Windows can use to run the encapsulated .app . DLLs in FoxPro are pretty much used only in XML Web Services. So the generation of a DLL for each project in .NET looks strange to FoxPro developers. FoxPro apps don't have to be compiled into an executable unless they're going to be used with the FoxPro runtime.

Many of the differences between the two languages stem from the fact that so many more output options are available in Visual Basic .NET. In the following sections, we'll look at the main differences in the components of the respective IDEs one by one.

Typing Commands in the Command Window

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 (like SET STEP ON ) to your code. (To set a breakpoint, you can click on the left margin in the Code editor, insert the line 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.)

The Toolbox

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.

TIP

Unlike FoxPro, where each open class library is a selection on the Class Picker toolbar context menu, there's only one User Controls toolbar in Visual Basic .NET.

Tab Ordering

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.

Projects and Solutions

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.

Compiler Output Formats

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.

NOTE

The name Dynamic Link Library (DLL) derives from the fact that they are linked when called (dynamically) rather than when the executable is created. So, you can run them from within other programs. They are said to run in-process as opposed to out-of-process in the non-FoxPro world, where components are compiled as DLLs; for us, the distinction is meaningless.

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

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.

The Document View Window

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 Task Lists

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.

The Server Explorer

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.

What Can You DO in the IDE?

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 .

The Class Browser and Visual Basic .NET's Class View

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.

The Object Browser

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.

The Properties Window

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:

1. Declare a private variable in the Declarations section of the class; the name should be an underscore followed by the name you used for the property procedure. A good time to do this would be just before creating the property procedure.

2. Add a Return _PropName statement in the Getter.

3. Add a _PropName = Value statement in the Setter.

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.

Getters and Setters Versus ASSIGN and ACCESS Methods

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.

Shortcut Keys

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.)

Table 1.1. Keyboard Shortcuts in Visual Basic .NET and Visual FoxPro

Feature	Visual Basic .NET	Visual FoxPro
Properties sheet	F4	Alt+W,P
Solution Explorer	Ctrl+Alt+L	Alt+W,Project Mgr, or Alt+F, New Project to create
Server Explorer	Ctrl+Alt+S	Like the Database Container or Data Environment
Class view	Ctrl+Shift+C	Alt+T, C
Object Browser	Ctrl+Alt+J	Alt+T, J
Compile and Run	F5	Ctrl+D, then select

The Tools, Options Dialog

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.

Table 1.2. Equivalents to the FoxPro Tools, Options Page Elements in the .NET IDE

FoxPro	Visual Basic .NET
View	Tools, Options, Environment, General.
General	No equivalent (FoxPro-specific).
Data	Connection- and DataAdapter -specific.
Remote Data	Connection- and DataAdapter -specific.
File Locations	N/A; Visual Studio controls file locations.
Forms	Tools, Options, Windows Form Designer; for templates, use Add Inherited Form from Solution Explorer context menu.
Projects	Source Control, General tab for SourceSafe settings
Controls	Add References in the Solution Explorer exposes the Add Reference dialog; the COM page lists registered COM objects, and has a BROWSE button for unregistered COM objects.
Regional	Environment, International Settings controls most; use the locale property of the dataset to set CultureInfo; FormatCurrency function; System.Globalization Namespace components can be used to override the System and User language and currency specifications.
Debug	Environment, Fonts and Colors sets colors in various windows. VS .NET debug settings involve features that Visual FoxPro doesn't have.
Editor	Text Editor, Basic and Text Editor, General tabs; The Visual FoxPro equivalent of some Visual Basic Text editor settings are found in the Edit, Properties dialog available while editing a text file. The Visual FoxPro Tools, Options IDE tab is used to set many of the VS Text Editor tab settings.
Field Mapping	FoxPro specific; I wish there were a Visual Basic equivalent.
IDE	Text Editor, Basic; Environment, Fonts and Colors;
Reports	In a Crystal Report, right click on the design surface and select Designer, Default Settings

The Task Pane Manager

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.

The Output Window and Your Application Menu

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.

Customizing the IDE

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.