Adding Visual FoxPro API Calls

Article
10/23/2006

To integrate your program with Visual FoxPro, you can call Visual FoxPro API routines. These API routines are functions you can call from any C or C++ program, including an .ocx or .fll file, that give you access to variables, manage database operations, and accomplish many other Visual FoxPro-specific tasks.

The following table lists the general categories of API calls available in Visual FoxPro. For details about individual API functions, see API Library Routines A-Z or API Library Routines by Category.

To use the Visual FoxPro API routines, you must include the file Pro_ext.h, available in the Visual FoxPro API directory. This file includes the prototypes for the functions and structures that allow you to share information with Visual FoxPro.

If you're writing an ActiveX control, you must also add calls to initialize and clear the API.

To add Visual FoxPro API routines to your ActiveX object

Use #INCLUDE to include the Pro_ext.h file along with any other required header files.
In the Constructor (Init method) of the control, call _OCXAPI( ) to initialize the interface to Visual FoxPro using this code:
```
_OCXAPI(AfxGetInstanceHandle(),DLL_PROCESS_ATTACH);
```
Include calls to the Visual FoxPro API as required in your object.
In the Destructor (Destroy method) for the object, call _OCXAPI( ) again to release the process created in the Constructor, using this code:
```
_OCXAPI(AfxGetInstanceHandle(),DLL_PROCESS_DETACH);
```

For an example .ocx file that includes calls to the Visual FoxPro API, see Foxtlib.ocx. For an example of an .fll library that includes calls to the Visual FoxPro API, see the sample programs in \Api\Samples directory that have the extension C: EVENT.C, HELLO.C, and so on.

If you use Visual FoxPro API calls in your ActiveX control, COM object, or .fll library, the code containing the calls is incompatible with other applications. You might therefore want to build one or more tests into the program to determine whether the object is being called from Visual FoxPro.

For example, if you're creating an ActiveX control using the Microsoft Foundation Classes, you can change the control's constructor code to include a test and then alert the user if the control has been called from a program other than Visual FoxPro:

if (!_OCXAPI(AfxGetInstanceHandle(),DLL_PROCESS_ATTACH))
{
   ::MessageBox(0,"This OCX can only be hosted by Visual Foxpro","",0);
      //Here you can do whatever you want when the host isn't VFP:
      // you might want to reject loading or you 
      // might want to set a property
      // saying that the host isn't VFP and the control will use other 
      // means to achieve it's purpose.
}

If you're creating an ActiveX control using the Microsoft ActiveX Template Library, use the following code:

if (!_OCXAPI(_Module.GetModuleInstance(),DLL_PROCESS_ATTACH))
{
   ::MessageBox(0,"This OCX can only be hosted by Visual Foxpro","",0);
      //Here you can do whatever you want when the host isn't VFP:
      // you might want to reject loading or you 
      // might want to set a property
      // saying that the host isn't VFP and the control will use other 
      // means to achieve it's purpose.
}

In this example, the control doesn't exit, and will continue running after the user has acknowledged the message. The strategy you choose depends on how you anticipate the control will be used. For example, if you detect that the control is being used outside of Visual FoxPro, you can set a flag that you test at each point in the control where you call the Visual FoxPro API. If the flag indicates that the control is outside Visual FoxPro, you can branch around the API call to an alternative means of accomplishing the same task.

Adding Visual FoxPro API Calls

See Also

Additional resources