BUILD PROJECT, BUILD APP, BUILD EXE, BUILD DLL, BUILD MTDLL, External

We don’t use the BUILD commands very often, though they represent some of our most frequent operations. These are command equivalents to the various Build options of the Project Manager—we almost always do it from there.

EXTERNAL tells the Project Manager that certain components are defined elsewhere and shouldn’t be considered missing in action.

Usage

BUILD PROJECT ProjectName FROM FileNameList [ RECOMPILE ]
BUILD APP AppName FROM ProjectName [ RECOMPILE ]
BUILD EXE ExeName FROM ProjectName [ RECOMPILE ]
BUILD DLL DLLName FROM ProjectName [ RECOMPILE ]
BUILD MTDLL MTDLLName FROM ProjectName [ RECOMPILE ]

BUILD PROJECT is the same as creating a project, sticking one or more items (programs, forms, menus, reports, etc.) in it and then choosing Build, Rebuild Project. It treats the first item you hand it as the main program and works from there. All file objects explicitly referenced in any item in the project are added to the project. That is, if one program calls another, the second program is added to the project. Then, if that program calls two forms, those forms are added, and so forth.

Items referenced only on lines containing macro substitution are not added to the project. It doesn’t matter whether the substitution involves the item name or not—if the program line contains a macro, BUILD PROJECT doesn’t check it out for references. Similarly, items referenced indirectly aren’t added. See EXTERNAL below for the solution in both cases.

BUILD APP and BUILD EXE take a project and create an executable program from it. BUILD APP makes a FoxPro APP file—to run it, you either need a copy of Visual FoxPro or the runtime loader program (in the case of VFP 7, VFP7Run.EXE, installed by default in C:\Program Files\Common Files\Microsoft Shared\VFP). BUILD EXE makes a “compact” executable file that can be run from inside Visual FoxPro or using the Visual FoxPro support files (see Help for your VFP version to see what those files are).

There’s not a huge difference between the contents of an APP or an EXE—an EXE is really an APP file with the runtime loader EXE glued to the front of it. If you want, your EXE might contain only the code to DO MyApp.APP, then the bulk of your application could live in an APP file.

Back in FoxPro/DOS, BUILD EXE accepted a couple of other keywords, STANDALONE and EXTENDED, which allowed you to specify what type of EXE to create. They’re not accepted in VFP (and, in fact, cause errors), so you can just ignore them.

BUILD APP and BUILD EXE have a weird relationship. If you already have a file of one type for a particular project, and you build the other type, the one you have is deleted without warning. For example, if you have a project called MyProj and you’ve created MyProj.APP, issuing BUILD EXE MyProj FROM MyProj erases MyProj.APP. The setting of SAFETY doesn’t matter—the file is gone, gone, gone.

BUILD EXE can also be used to build an Active Document application. To do so, the project must contain a class based on the ActiveDoc base class, and that class must be marked as the Main program.

BUILD DLL and BUILD MTDLL are part of the world of components (BUILD MTDLL was added in VFP 6 Service Pack 3). They’re for creating a custom in-process Automation server from your project—they correspond to the Single-Threaded COM Server and Multi-Threaded COM Server choices in the Build dialog, respectively. To build a DLL, at least one class in the project must be marked as OLE Public. The result of either of these commands is a dynamic link library from which appropriate classes can be instantiated. The “Scalability and Multithreading” topic in the VFP Help file has information on the difference between these two types of DLLs.

If you have any OLE Public classes in the project, BUILD EXE also creates a COM server, albeit an out-of-process one. See “It Was Automation, You Know” in Section 1 for details on out-of-process versus in-process COM servers.

The RECOMPILE keyword indicates that all the individual components of the project should be recompiled before the appropriate result is built. This is the same as checking the Recompile All Files check box in the Build dialog. We sure wish the other options from that dialog were available in the command version. Well, okay, maybe we don’t need Display Errors—after all, we’re building the thing in code, but what about the options to run after building and to regenerate OLE Server IDs?

Example

BUILD PROJECT MyProj FROM MyProgram
BUILD APP MyProj FROM MyProj
BUILD DLL MyOLEProj FROM MyOLEProj RECOMPILE
BUILD MTDLL MyOLEProj FROM MyOLEProj

Usage

EXTERNAL FILE FileList | ARRAY ArrayList | CLASS ClassList
        | FORM FormList | LABEL LabelList | LIBRARY LibraryList
        | MENU MenuList | PROCEDURE ProcList | QUERY QueryList
        | REPORT ReportList | SCREEN FormList | TABLE TableList

EXTERNAL’s role in life is to tell the Project Manager about things. In most cases, you use it to trick the PM into including a file in a project when you haven’t directly referenced it. This is useful when a particular item is called only via a macro or indirect reference. Without the EXTERNAL statement, it doesn’t get added to the project or built into your APP or EXE. Pretty embarrassing to install at the client’s site and have a “File does not exist” error pop up. EXTERNAL also helps you to track all the oddball little files your project needs, so that you could rebuild your project from your main program without a problem—a nice backup for the Project Manager files.

Because EXTERNAL doesn’t take the complete path to the file in question (it simply ignores the paths you provide in the filename and uses only the path you’ve SET), you may need to point VFP to the specified files the first time you build the project after adding EXTERNAL declarations.

For arrays, EXTERNAL serves a slightly different role. When you pass an array as a parameter, it’s listed just like any other variable in the parameter list. FoxPro has no clue that it’s really an array. So, when you use that variable as an array in the routine, the compiler yells at you, thinking it’s found a function call for which it can’t find the code. Putting EXTERNAL ARRAY in the routine with the array parameter clues the compiler in.

Example

FUNCTION aIsArray

LPARAMETER aTestArray      && We know it's an array.
EXTERNAL ARRAY aTestArray  && Now the compiler knows.

See Also

ActiveDoc, Compile, Create Project, Do, Modify Project, Parameters