Foxfire! Object Model

This is an overview of the Foxfire! Object Model, provided so developers can get a better understanding of the direction Foxfire! is moving and how to take advantage of it and start planning better reporting in their own applications.

Version 1.0 of the Foxfire! Object model is shipping with versions of Foxfire! 6.02 from June 1^st onwards. Any developer who purchased Foxfire! 6.02 will be permitted to download version 1.0 of the Object Model from the web site.

The purpose of the object model is to provide a component (in COM and in Native VFP) that users can use to review and document reports as well as to create and run reports programmatically without having to rely on the existing Foxfire! user interface.

FFApplication

The main component or class of the object model is the FFApplication class. This class alerts the other components as to the location of Foxfire! and where the various files are.

Two of the key methods in FFApplication are SetLocation and LoadPreference. When you first instantiate the FFApplication object, you need to tell it where Foxfire! is located. After the object has found Foxfire!, then it can proceed to load in the preferences. You may also pass it the Preference name and have it load in the specific preferences. Once the preferences are loaded in, users have direct access to key components of the preference.

Object Model High Level

Here is a diagram showing the FFApplication after the LoadPreference has been loaded. The Foxfire! object model has collections for Preferences, Requests, Joins, DataItems and Styles so users can easily manipulate the various entries. Note that all of the collections respect the filters originally set in the Preference sets.

Here’s some sample code showing how a program might access the Object model and display the number of requests in a specific preference set. Note the passing of “Demo Use of Views” to LoadPreference. If this is not done, the default preference will be loaded.

Application Methods

In the FFApplication component, all of the methods return numeric codes: 0 meaning success and all negative values indicate an error. Users can find an English translation to the error by calling ErrorInfo and passing the Error number.

Collection Objects

As noted before, the FFApplication object exposes the following collections for direct access to developers.

Collection Methods

Since Visual FoxPro 7 does not directly support collections, we have created a variety of methods to help making them easier to work with.

The Find() method lets you specify a key value and will set the currently SelectedItem property to the item found.

The SetIndex() works similar to Find only it uses the Record number or “index” to identify which item is the SelectedItem.

The Items() array lets you pass either the Key or the Index which is very valuable for identifying what you want to work with.

A Foxfire! Request

Let’s drill down a little further and take a look at the Request object. Within each collection, you can access all of the properties for a particular item. The Foxfire! Request object has its own collections for DataItems, Sort items and Filters. Each item in the lower collections point to a “DataItem” and then add subsequent properties for setting the request up accordingly.

Properties

The Request Object uses English names to make it easier to refer to. RequestName is the name of the request, Description, OutputType, etc. This makes your code easier to read.

Common Item Methods

From within an Item, you can Update( ), Delete( ) and even Add a new entry.

If adds are not permitted, the Add method returns -5501.

Object Model Support

It’s important to note what the Object Model in version 1.0 supports. Running reports is not directly supported however, we do provide a mechanism to run them using the standard Foxfire! engine.

Another omission from version 1.0 is Ask At Runtime and dialog support. When running a report programmatically or from within a COM component, you don’t necessarily want to pop up a dialog in another application. Therefore, we have limited access to these options. If you run a request with Ask-At-Runtime, it will either Return without completing or simply use the Default values.

Running Reports

Although the object model does not provide direct support for running requests within the component, it does provide a call to permit users to run the request. In future versions, this call will be expanded to run the request directly within the object model.

The RunRequest method runs the actual request by calling Foxfire! in batch mode. If you attempt to run a report that is directed to the screen, it will simply run the request but not provide the output.

Code Samples

Running Requests

SET CLASSLIB TO VFOXFIRE

loFF = CREATEOBJECT(“FFAPPLICATION”)

IF loff.SetLocation(“C:\FF60”)=0

IF loFF.LoadPreference()=0

loFF.RunRequest(“INVENTRY”)

ENDIF

Listing Requests

X = createobject(“ffapplication”)

x.SetLocation(“C:\FF60”)

x.LoadPreference()

FOR lni = 1 TO x.Requests.Count

? x.Requests.Items(lni).RequestName

ENDFOR

Building a new report

X = createobject(“ffapplication”)

x.SetLocation(“C:\FF60”)

x.LoadPreference()

loRep = x.Requests.Add( “Detail” )

loRep.DataItems.Add(“Cars Make”)

loRep.DataItems.Add(“Cars Model”)

loRep.Sorts.Add(“Cars Make”)

loRep.Sorts.Add(“Cars Model”)

loRep.Groups.Add(“Cars Make”)

loRep.OutputType = “Spreadsheet”

loRep.Update( )