Class documentation is provided for all public classes and all public interfaces. For the most part, use of this documentation should be self explanatory.
The main Class Reference page contains an alphabetical list of all classes along with a short description of the class. You can choose to view this list for windows applications, web applications or both. You may also choose to view only the public classes (filtering out all abstract classes).
The Hierarchy page displays the class hierarchy. You can view the hierarchy for web application classes, windows application classes or the combined hierarchy.
Both the class list and the hierarchy page provides links to each class documentation page. This page contains a full description of the class and links to all of the public interfaces: properties, events and methods (procedures and functions). These interfaces are provided in a list accompanied by a short description for each item and a link to documentation for each interface. When you view a list of interfaces (properties, events, methods) you will be shown a complete list of the class interfaces including all super-class interfaces. This list is presented in class hierarchy order where interfaces are grouped within the class that defines them. You can also choose to view these lists in alphabetical order. This makes it easy to find the message you need without having to search through the entire class hierarchy.
Note that only non-private classes (public and abstract) and public messages are documented. Private classes and interfaces are part of the internal implementation and therefore should not be used by the developer. For that reason, they are not documented. When debugging applications you will, of course, still see these messages.
The DataFlex Studio provides quick contextual access to the referential documentation - class and command. When inside the Studio's editor, place the cursor over the word you wish to research and press F1. The help system will be invoked and an attempt will be made to find the keyword in the help system. If the search keyword is a class name (e.g. Button), the class documentation page will be loaded. If the search keyword is an interface (e.g. OnClick) and that interface name is unique, the page for that interface will be loaded. If the name is not unique (e.g. Value), a list of choices will be presented.
You may also use the F1 feature to search for command documentation (e.g. Move).
The class documentation structure is imported directly from the package source code. This insures that all classes and interfaces are always up to date and accurate. All of the packages contain special markup code that enable us to import the proper information. These are referred to as meta documentation commands and take the form of "//doc/ ...".
While you do not need to understand how the meta tags are used, you may wish to understand the concepts they represent in our class library. Here is a quick summary:
This represents the different attributes of a class.
A class marked Public can be used for both sub-classing and object instantiation by the developer. Public classes are documented.
An Abstract class is a class that should never be used for instantiation and rarely used for sub-classing. It is usually an intermediate class that is needed to create a Public sub-class. While an Abstract class is not used for object instantiation or custom sub-classing, its interfaces may be used by its sub-classes and requires documentation.
A mixin class is a class that is always based on the Mixin class and is used to mix "skills" into other classes. They are never used for sub-classing or instantiation. A mixin class's interface is directly added to the class that imports the mixin skills. Accordingly, mixin class interfaces will be documented as part of the class that uses the mixin.
A class marked as Private, is used internally and should never be used by the developer. These classes are never documented.
A class can be used for Windows applications, web applications or both (Common). A class's library type is defined with the Class Library meta documentation command.
If a class library type is not specified, Windows Application is used.
These are the different types of method types we support. Most of their meanings should be obvious. Within the documentation we will have three interface sections: Properties, Events and Methods. Properties can be defined using the property command or by using the Procedure Set / Function methods. Events are usually defined as a Procedure although they can also be defined as a function. Methods are defined as a Procedure, a Function or, in rare cases, as a Procedure Set.
The Procedure Set type is rarely used. Normally a method defined with "Procedure Set" has a corresponding "Function" and is defined as a property. In some cases, Procedure Set is not used as a property but is used as an alternate syntax for a procedure and will be documented as such. The Procedure Set type exists to support old, and now discouraged, interfaces. If you create a new Procedure Set method, you are encouraged to only use this to define a property. If it is not a property, define the method with the Procedure command.
A property, event of method can be either public or private. If public, the method is documented. If private, the interface is part of implementation detail, should not be used, and is not documented.
Classes and interfaces (events, methods, properties) may be designated to be obsolete. An obsolete class or method still exists, may still be used and might exist in your application. It should not be used for new development as a better non-obsolete solution has replaced it. If the class or method is public and obsolete it will be documented. However, you should never use obsolete interfaces when creating new work.