The LA Fox Developer Newsletter

September 1997

ActiveX (Con’t from page 4)

Some ActiveX controls may expose a property sheet via the

shortcut menu. In VFP, all of the object’s properties and

methods are also exposed in the VFP Properties sheet. This

makes using ActiveX controls nearly identical to any other

class.

VFP 3 does add a twist to this: it does not receive ActiveX

events. For example, if your ActiveX control triggers a Windows

event, VFP3 will know nothing about it. This may be a critical

shortcoming for some controls. It all depends on the control

and its usage.

Case Study: ChartFX

Background

Our application called for a way to visually display data. We

already provided a means to export data to Excel, and once

there, could be graphed, however this task is beyond most

users. We needed to keep it simple. ActiveX controls, due to

their size cannot possibly provide the feature set of a large

application. In this case, the relatively limited functionality of

ActiveX controls was just what we needed - something small

and easy to use. Experienced users who want more would still

be able to export data to a more full-featured graphing applica-

tion.

There are many very good graphing packages available, includ-

ing Pinnacle’s Graphics Server, ChartFX, etc. There were four

that stood out and their feature set was nearly identical. Some

provided a better object model than others, but the one we

decided on was SoftwareFX’s ChartFX due to its superior end-

user interface.

A Brief Review of ChartFX

The most outstanding feature is it’s exposed end-user interface

available at run-time. It has received a tremendous response

from our user base and actually receives applause during

customer train ings. However, it is not built with an exposed

object model. There is a great deal of flexibility available

programmatically, but most of the properties are used to store

multiple values using bitwise operators. Bitwise operators may

be familiar to C developers, but to others it may take some

getting used to.

The hard-copy documentation just adds weight to the box.

However the on-line help is quite thorough, although it is not

indexed well at all. Finding what you’re looking for is some-

times very difficult. The documentation also provides many

examples for several platforms generally including C++, VB,

VFP and Delphi. The product ships with sample code for each

of these platforms as well.

SoftwareFX maintains a very good web site as well as a

CompuServe forum. Technical support is handled through one

person, but I’ve always received excellent service via phone, e-

mail, or CompuServe. Product updates are posted on the web

site when available, generally monthly. The updates contain

only code changes, but a program is available from the web site

to merge the delta files into the OCX.

As with most ActiveX controls, ChartFX requires a substantial

wrapper to make it reusable within VFP applications. This is

not to say that it is difficult to work with, just that you will want

to create the wrapper to expose an interface more familiar to

your other VFP developers. This also allows you to customize

the control to fit your application.

The Design Challenge

The challenge in designing this graphing tool is to make it

flexible enough that it can be used with any data, from any grid,

in the system. The data sources for these grids are the results

of queries written on-the-fly based on user input.

The most common type of data is a simple query result with

multiple rows of data and several fields, including numerous

“key” fields and other “value” fields. We’ll let the user select

which fields will be used in the graph and what type of graph to

display.

After looking at how data is loaded into the graph, it was

determined that there are three basic graph types requiring data

to be loaded in three distinct formats: bar/line, scatter, and pie.

The ChartFX control can display other graph types, including hi-

low graphs, but we’ll stick with the three basics for now. The

format that the data is in as a result of the initial query may not

be appropriate for loading into the graph. Therefore, a transfor-

mation needs to be done prior to loading the data into the graph.

Exactly what form the data needs to take depends on the user’s

selections.

Object Design

There are basically three objects that will accomplish this task:

the engine, the wizard, and the graph. Each object can vary

independently of the others so that each component can be

written for specific cases. For example, a cross-tab grid may

use a different engine and a time-series may not use a wizard at

all.

The Engine

The engine is a non-visual control that knows how to talk to the

grid (to get table structure information), how to get input from

the user (using the wizard), how to build the SQL-SELECT, and

finally how to display the graph.

The Wizard

The wizard is the user-interface. The only thing it knows how to

do is interact with the user. The engine will query the wizard

when it needs to know something.

The Graph

Once the SQL-SELECT has been run, the en

graph (or the form containing the graph) and t

data and display itself. The graph can receive

that it can format itself, set the graph type, lo

display series legends.

(Con’t, page 6)

Page 5