This field retrieves the internal action table of a class. The action table is arranged into a jump table of action routines, with each routine pointing directly to the object support functions. The size of the jump table is defined by the global constant AC::END. The table is sorted by action ID.

It is possible to check if an action is supported by a class by looking up its index within the ActionTable, for example Routine[AC::Read]. Calling an action routine directly from client code is an illegal operation.

Action routines are associated with a new class by referring to a list of ActionArray items in this field. Each provided action ID must be paired with its associated routine.

Internally, the provided list is copied to the ActionTable and the original values will serve no further purpose.

The following example shows a list of ActionArray structures borrowed from the Picture class. Note that such lists can also be auto-generated using our IDL scripts - an approach that we strongly recommend.

ActionArray clActions[] = {
   { AC::Free,          PIC_Free },
   { AC::NewObject,     PIC_NewObject },
   { AC::Init,          PIC_Init },
   { AC::Query,         PIC_Query },
   { AC::Read,          PIC_Read },
   { AC::SaveToObject,  PIC_SaveToObject },
   { AC::Seek,          PIC_Seek },
   { AC::Write,         PIC_Write },
   { 0, NULL }
};

Note: Never refer to method ID's in an action list - the Methods field is provided for this purpose.

The BaseClassID must always be set prior to the initialisation of a new MetaClass object unless ClassName is considered sufficient. If the BaseClassID is zero then the hash of ClassName is computed and set as the value of BaseClassID.

When defining a sub-class, it is required that the BaseClassID refers to the class that is being supported.

When designing a new class it is recommended that a suitable category is chosen and declared in this field. It is acceptable for a class to be a member of multiple categories by combining category flags together.

The ClassID uniquely identifies a class. If this value differs from the BaseClassID, then the class is determined to be a sub-class. The ClassID value always reflects the strihash() computation of the ClassName, and is automatically set on initialisation if not already set by the client.

This field specifies the name of the represented class. Characters should be limited to those in the range of A-Z and written in camel case, e.g. KeyValue and not Keyvalue or KEYVALUE. Setting this field value is compulsory prior to initialisation.

This field value must reflect the version of the class structure. Legal version numbers start from 1.0 and ascend. Revision numbers can be used to indicate bug-fixes or very minor changes.

If declaring a sub-class then this value can be 0, but base classes must set a value here.

Following initialisation of the MetaClass, the Dictionary can be read to retrieve the internal field lookup table. For base-classes, the client can use the binary search technique to find fields by their ID. For sub-classes, use linear scanning.

This field points to an array that describes the structure of objects that will be generated for this class. It is compulsory that base classes define this array. Sub-classes will inherit the structure of their base, but they may set Fields with additional virtual fields if desired.

Refer to the Parasol Wiki on class development for more information.

This field allows you to specify a description of the class' file type, if the class is designed to be file related. This setting can be important, as it helps to distinguish your class from the other file based classes. Always make sure that your file description is short, descriptive and unique. A file description such as JPEG is not acceptable, but JPEG Picture would be appropriate.

This field describes the file extension/s that the class will recognise. For example: *.wav|*.wave|*.snd.

Use of the vertical bar allows more than one file extension to be supported by the class. The file extension that is preferred for saving data must come first.

If a class supports file data, then the FileHeader field is used to identify the types of data that the class supports. This feature is used by routines that need to analyse files and determine which classes support them.

For example, the JPEG class supports files that start with a 32-bit token to identify them as JPEG. Declaring a FileHeader expression to match these tokens will allow the FileView feature to detect JPEG files and display an appropriate icon for each JPEG entry in the file list.

The expression format is [Offset:Value]...

The offset is an integer that identifies the byte position at which the given Value will be present. The Value is expressed as a hexadecimal number if it is prefixed with a dollar sign $, otherwise the Value is treated as case-sensitive text. Multiple expressions can be specified in sequence if there is more than one comparison to be made - so [0:$ff][8:$fe] would require $ff at offset 0 and $fe at offset 8 in order to generate a match.

In some cases, a series of unrelated token sequences may need to be used to match against files. This is true for the JPEG class, which supports three different tokens all at offset 0 for identification. Each matching sequence must be separated with an OR symbol | as demonstrated in this example for the JPEG header: [0:$ffd8ffe0]|[0:$ffd8ffe1]|[0:$ffd8fffe].

Files that belong to a class can be associated with an icon that is declared in this field. The icon string format is folder/icon. Valid icons are available in the icon database.

The path from which the class binary was loaded is readable from this field. The path may not necessarily include the file extension of the source binary.

If a class design will include support for methods, create a MethodEntry list and set this field prior to initialisation. The array must provide information on each method's ID, name, parameters, and structure size.

Note that method lists can be auto-generated using our IDL scripts - an approach that we strongly recommend.

This field will compile a list of all objects that belong to the class. The list is sorted with the oldest object appearing first.

The resulting array must be terminated with FreeResource() after use.

This field reveals the total number of objects that reference the class. This figure will fluctuate over time as new objects are created and old ones are destroyed. When the OpenCount reaches zero, the Core may flush the Module that the class is related to, so long as no more programs are using it or any other classes created by the module.

The Path field must be set on initialisation and refers to the default location of the class' module binary, for example modules:display. For reasons of platform portability, the file extension must not be specified at the end of the file name.

This field value must indicate the byte size of the objects that will be created from the MetaClass. For example, the Picture class defines this value as sizeof(objPicture).

If the size is not explicitly defined, the initialisation process will determine the structure size by evaluating the field definitions that have been provided.