The Visual Basic .NET Solution Explorer

The distinction between FoxPro's Project Manager and Visual Basic .NET's Solution Explorer was touched on earlier, but there are additional important differences.

FoxPro groups every project into five classes of elements, as indicated by the tabs at the head of the Project Manager:

• Data lists excluded tables as well as files that define queries and views.

• Documents contains screens (forms), reports , and labels.

• Classes lists all Visual Class Libraries contained in your project.

• Code includes PRG files for standalone programs, procedures, or class libraries in code.

• Other holds menus , graphics, and miscellaneous text files.

Items can be listed in the project file but are marked as excluded, so that they are not part of the executable and can be modified. For example, by default DBFs are marked as excluded in the Project Manager. If a DBF (say a table of States) is included in the executable, it can be read but can't be modified. This is sometimes useful, but rarely. Items that are in the current directory but haven't been included in the project don't appear in the Project Manager files list.

TIP

I once saw a clever use of a DBF embedded in the executable. In a multiuser FoxPro application running on a Local Area Network (LAN), the programmer added a "licenses" table containing 10 records. Then, whenever a user logged on, he used LOCATE FOR NOT RLOCK() . If he found a record, he issued an RLOCK() . As users logged out, the records were unlocked. After 10 users, no more records could be found.

Finally, if you create an empty project and add your MAIN program, the BUILD PROJECT command will start by reading all components referenced in MAIN and then follow the rabbit trail until the project has been rebuilt.

There is no corresponding automatic discovery process in Visual Basic .NET. You have to add files to a project manually, one at a time. Click on the Show All Files button to see files that are located in the project directory. The icon beside each file's name indicates whether it's included in the project or not.

In Visual Basic .NET, when you create a project, a solution of the same name is also created, with a hierarchy consisting of a bin and a debug directory. In the Solution Explorer there's a Show All Files button; when you click it, all of the files in the application directory are displayed. You can right-click on them and include them in the build. Once the files are included, the Properties window gives you several options for the build action ”none, content, compile, or embedded resource.

All of the code files in a project must be written in the same language. However, you can build a solution with one Visual Basic ( .vb ) project and one C# ( .cs ) project, and they'll make beautiful music together. This is, of course, because both have been translated to Intermediate Language by the time the solution is built, and neither one cares which boat the other's ancestors arrived on.

Intermediate Language

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.

TIP

You can generate typed datasets directly from the command line if you have an XML schema. You can get the XML Schema from SQL Server using the FOR XML AUTO&Root=Root option, or from any other source. Open a Visual Studio command window, use the command XSD ( filename .xml) to create an XSD file, and then use XSD ( filename .xsd) “c /l:VB to generate a Visual Basic typed dataset class. Or you can simply right-click on a data adapter at the bottom of a form and select Generate Dataset.

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.

DLLs

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.

Other Characteristics of a Visual FoxPro Project

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

Using Tables to Store FoxPro Project Components

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.

NOTE

Long ago, Windows performed poorly when more than 127 files were located in any single folder. As a result, it was customary to distribute the elements of Visual FoxPro projects into Screens, Reports, Data, and Other folders. That's no longer necessary.

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

TIP

If you want to ship someone your screens or class libraries without giving them source code, you can compile both VCX and SCX files, and erase the code in the Methods memo field. The compiled code in the ObjCode field is all the user's FoxPro compiler needs to build the executable.

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.

File Types Used in Visual Basic Projects

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.

Project Information

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.