5
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 application.

There are many very good graphing packages available, including 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 sometimes 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, email, 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 transformation 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

5