FormDirector supports storage and retrieval of several types of data. This data includes:
The concept of a form set in the forms processing world is described simply as a collection of zero or more forms. FormDirector implements this concept as the type FormSet. This type exposes several parameters to allow storage of various attributes of a form set.
FormDirector also implements the type FormSetFile, which derives from the FormSet type and adds the capability to write and read itself from persistent storage.
The primary purpose of the FormSet type is to represent a collection of forms, in order to support form identification. As a result, the core part of a FormSet is a collection of FormDefinitions, the FormDefinitions property. If you do not need to perform form identification, then you probably do not need to use a FormSet object and can rely instead on one or more FormDefinition objects.
A secondary purpose of a FormSet is to hold data, including a name of the form set, parameters for form identification, parameters for other image operations, and some miscellaneous data.
The FormSet class is an abstract class which defers the details of reading and writing form set files to a derived class. FormDirector provides a derived class, FormSetFile, which implements reading and writing data to files for persistent storage. You can create your own derived classes to manage reading and writing to other locations, such as a web server or database.
To see a full list of attributes and operations of the FormSet class see the FormSet Members page. See also the FormSetFile Members page.
Form director implements the real-world concept of a single-page form as the type FormDefinition. This type exposes several parameters to allow storage of various attributes of a single-page form.
FormDirector also implements the type FormDefinition file, which derives from the FormDefinition type and adds the capability to write and read itself from persistent storage.
The primary purpose of a FormDefinition object is to represent a single-page form, in order to support form identification and field-level processing of a form. As a result, the core parts of a FormDefinition object are a template image and a collection of Fields.
A secondary purpose is to hold data that is stored persistently in a form definition file, including the name of the form, parameters for form processing, and some miscellaneous data.
The FormDefinition class is an abstract class which defers the details of reading and writing form definition files to a derived class, FormDefinitionFile. You can create your own derived classes to manage reading and writing to other locations, such as a web server or database.
To see a full list of attributes and operations of the FormDefinition class see the FormDefinition Members page. See also the FormDefinitionFile Members page.
The concept of a field in the forms processing world is described as a single rectangular region on a form defined by pixels, along with a type, and various other attributes. Frequently, a field will contain a single user-filled item, such as a last name or phone number.
FormDirector implements this concept as the type Field. This type exposes several parameters to allow storage of various attributes of a field.
In FormDirector, a Field is associated with exactly one FormDefinition, and a FormDefinition is associated with zero or more Fields. When a FormDefinition is written to persistent storage, all of the associated Fields are written to persistent storage at the same time. And, when a FormDefinition is retrieved from persistent storage, all of the associated Fields are retrieved at the same time.
The primary purpose of a Field object is to contain the parameters you need to process a single field on a form. Those parameters are a rectangle, measured in pixels relative to the top left corner of the template image; a set of construction parameters, a set of processing operations, and some miscellaneous data.
To see a full list of attributes and operations of the Field class see the Field Members page.
FormDirector provides various specific holding areas for descriptive parameters and attributes of form sets, forms, and fields. FormDirector exposes two data types to support storage of template images: operation control parameters and custom data. With the help of these two data types, almost any type of data can be managed by FormDirector.
The concept of a template image (or just template) in the forms processing world, is described as a full image of the original form, without any additional data added to it. FormDirector implements the concept of a template image as the type TemplateImage.
The TemplateImage type is made available to enable the storage of 1-bpp (bit per pixel) images of a blank form. Each TemplateImage is intended to be associated with only one FormDefinition, and a FormDefinition instance normally will only have one Template image associate with it. However, there is support for associating more than one TemplateImage with a single FormDefinition. When a FormDefinition is written to persistent storage, the associated TemplateImages are also written to persistent storage. And, when a FormDefinition is read from persistent storage, the associated TemplateImages are also read from persistent storage. The actual image data stored within a TemplateImage object and in persistent memory are compressed.
Learn more about the TemplateImage Class.
Control parameters can define and describe operations that are to be performed at various places in a forms processing application. Custom data is any data, which may not be related to operations that needs to be associated with a particular Field, FormDefinition, or FormSet. To represent control parameters and custom data, FormDirector implements the type DataItem.
The DataItem class has an attribute named Type that describes the type or purpose of the data stored within the object. The class also has an attribute named Content to store the control parameters or custom data.
Each of the types Field, FormDefinition, and FormSet have multiple attributes that are represented by the DataItem class. Some of these attributes have specific purposes:
In addition to these two special-purpose attributes, FormSet, FormDefinition, and Field objects each have two general-purpose attributes, to hold ordered collections of DataItem objects:
| Operation | Description |
| FormSet Operations | FormSet Operations typically include instructions for ScanFix operations such as deskew, that you will perform before form identification. While FormSet Operations are normally clean-up or enhancement operations, you could store other things here, such as scanner parameters. |
| FormDefinition Operations | FormDefinition Operations typically include instructions for some ScanFix image enhancement tasks, but the list of FormDefinition Operations might also be empty depending on your imaging needs. Operation instructions are typically performed after form identification, but before processing fields. |
| Field Operations | Field Operations will almost always end with instructions for a data capture operations, such as Auto Classification, OCR, ICR, or OMR. Often, Field operations begin with instructions for ScanFix image enhancement parameters. If you want, this would be a convenient place to store some types of data validation operations. If you are using a third-party component to perform some of your field processing, you could store those parameters in this area. |
| OtherDataItem | Description |
| OtherDataItem Collection |
The OtherDataItems collection is intended to store custom attributes of your form sets, forms and fields. For example, you could use these collections to store database ID's. FormFix uses these collections to store information it has gleaned from forms and form sets. |