OCX Charting File Names

ProEssentials includes 5 ActiveX interfaces: Graph, Scientific Graph, 3D Scientific Graph, Pie Chart, and Polar Chart controls.

Note that the OCX file names (and DLL filenames) have changed from version 3, 4, 5 and version 6. The class-ids have changed also. This means you can have a v3, v4, v5, v6 and v7  ProEssentials based application on the same system with no worry of conflict.

We mention the DLL file names above because the ActiveX interfaces derive their core charting functionality from the ProEssentials' DLL.  Anytime you distribute the ActiveX Charting interfaces, you will need to include the DLL.  More on this later when we discuss deployment.

Program and Class IDs

If you're wondering what a [Program ID] and [Class ID] are: The [Program ID] is used within ASP or Visual Basic in conjunction with the CreateObject function call.  Essentially its programmatic name.  [The Class ID] is a similar naming convention used within HTML. The following HTML Object tag will create an instance of a control within a web page.

ActiveX Charting Model

The ActiveX Charting interfaces have a simple object model that closely resembles our DLL interface.  Within the property reference material, at the top of each property topic, you'll see a table with various property attributes.  For example, the property FontSize has such an entry.

If developing with either OCX or VCL interfaces, you'll refer to this property via the OCX|VCL row heading.

For a control named Pego1, to programmatically control the FontSize property within code, you'll write...

Don't use property windows!

We recommend that you set only a few properties (if any) in the property window/object browser. This has many advantages: 1) If you have problems, you can email/fax us your code and we have a record of what properties you are setting; 2) If you go back to your code a couple months later, or someone else inherits your project, they have a documented list of properties you have set; 3) If you ever port your code to another IDE, its very easy to just reformat your current code; 4) In the case where a VB or Delphi form-file gets corrupted (this does happen occasionally) you won't lose your property adjustments; and 5) You will avoid potentially hard-to-find bugs due to setting a property both in the property window and in code.

The bottom line is that property windows may seem to be faster, yet, in the long run, coding your property settings will definitely result in the fastest, safest, and most maintainable implementation.