Automation Server Programming Notes

Article
11/14/2006

You can find additional information on writing automation servers in the following locations:

The Application Object

The Application object is not exposed in an Automation server type library, therefore you cannot access the Application object DoCmd and Eval methods. You can expose the Application object by creating a custom property and setting its value to the Application object, or you can provide a method that accesses the Application object.

Read/write properties of the Application object such as AutoYield are global to the project, so ensure that your multithreaded servers do not assume that the values of these settings are protected across threads.

Automation Server Samples

This version of Visual FoxPro includes two sample ISAPI Automation servers, FoxWeb and FoxIS. These samples manage the return of selected Visual FoxPro records to an Internet browser as HTML. For more information about these samples, see FoxISAPI: An OLE Server Sample.

Note FoxISAPI included in Visual FoxPro includes improvements designed specifically for use with new multithreaded DLL Servers. DLL Servers run through FoxISAPI should not use the built-in Pool Manager.

Configuration Files

In Visual FoxPro, only CONFIG.FPW files bound inside of either EXE and DLL servers will be used during run-time initialization. The Configuration file stores critical settings that are set at the time Visual FoxPro starts up (both product and run time). Prior to Visual FoxPro 6.0, the CONFIG.FPW file could exist as a separate file or bound into the application (.app, .exe or .dll). If a CONFIG.FPW file is found bound into an application, then it is used, otherwise Visual FoxPro searches along normal paths for a separate CONFIG.FPW file.

You will still get full functionality with normal distributed .app and .exe applications.

Codepage Handling

Codepages are supported in all servers and are specific to a particular project (.dll). The default codepage can be set in the CONFIG.FPW file and is set only at run-time initialization. The codepage is global across all projects. All objects using a particular instance of the run time will share the same codepage. Because there is a potential for multiple .dll servers to change the default codepage for a run time (that is, each server has its own CONFIG.FPW with a different codepage setting), Visual FoxPro prevents changing this setting once the run time has been launched. So, once a codepage is set, it is permanent until the run time is released.

Users who need to have servers, each with a unique codepage, can place these servers, along with a copy of the vfp8t.dll run-time library in a unique folder. A server will always default to using a run-time library stored in its folder.

Special Language Considerations

There are several commands that you need to be aware of when working with automation servers since their behavior differs slightly from normal product operations.

SET PROCEDURE

Since this command is stored in thread local storage it is unique to each individual thread. However, by default, when you instantiate either an .exe or .dll COM server, Visual FoxPro implicitly performs a SET PROCEDURE to the entire server. For example:

? SET("PROCEDURE")
C:\VFP\MYSERVER.DLL

This makes it possible for you to access any procedure stored in the server. If an existing object on the thread calls SET PROCEDURE TO, then the procedure path is reset to nothing; however, a new object created on the same thread will automatically reset the procedure path to the entire server once again.

SET CLASS

This command works similarly to SET PROCEDURE. Its value is held in thread local storage, however, it is initialized to the entire set of class libraries in your .exe or .dll server. For example:

? SET("CLASS")
C:\VFP\myClass.VCX ALIA

CD, CHDIR, SET DEFAULT Commands

These commands change the default directory of the entire process, so all threads which are part of the process are affected. Use the SET PATH command instead of CD, CHDIR, and SET DEFAULT.

Share via