In a form processing application FormFix provides three pieces of essential functionality:
These pieces are applied at different times in the control flow. This page will first show how to create control parameters for any FormFix operation and how to place those control parameters in a DataItem. It also discusses how to use FormDirector to store and retrieve processing data on behalf of FormFix.
The process described below applies to all FormFix operation classes. For this example, we are describing the procedure for the IdentificationProcessor class.
This section talks about storing control parameters for various FormFix operations.
The FormFix identification operation is central to a form processing application that allows unknown images as input, and/or needs the input filled image to be aligned to the template for field level operations.
Form identification control parameters are stored in the Content string of a DataItem. The Type string of a DataItem should be “FormFix/Identification”. This DataItem should always be the Identification property of a FormSet.
The FormFix dropout/clip operation is essential to a form processing application that does data acquisition at a field level, and therefore requires field clips.
Form dropout/clip control parameters are stored in the Content string of a DataItem. The Type string of a DataItem should be “FormFix/DropOut”. This DataItem should always be the Creation property of a Field object.
The FormFix OMR processing operation is used to perform optical mark recognition on fields. To learn more about the capabilities of the FormFix OMR processor, see the FormFix help file.
OMR control parameters are stored in the Content string of a DataItem. The Type string of the DataItem should be “FormFix/OMR”. This DataItem must be associated with a Field object by adding it to the Field object’s Operations collection.
The FormFix automatic field type classification operation is used to identify field content as either ICR or OCR. To learn more about the capabilities of the OCR/ICR field type classifier, see the FormFix help file.
Control parameters are stored in the Content string of a DataItem. The Type string of the DataItem should be “FormFix/FieldTypeClassificationProcessor”. This DataItem must be associated with a Field object by adding it to the Field object’s Operations collection.
FormFix may ask the form processing application to information on its behalf during form processing. The form processing application can use FormDirector to store and retrieve this information, and also write this information to file.
FormFix uses the WriteDataItem events to indicate that it has generated information about a form image or a form set, and through these events it is providing that information to the application code to store the information for retrieval at a later time. The application can handle the WriteDataItem events and stick the information provided in the event arguments into the Content and Type property of DataItem object. The application should stick these data items in different places depending on what object raised the WriteDataItem event. If an Accusoft.FormFixSdk.IdentificationProcessor triggered the event, then the DataItem should be placed in the OtherDataItems collection of a FormSet object. If an Accusoft.FormFixSdk.FormModel triggered the event, then the DataItem should be placed in the OtherDataItems collection of FormDefinition object that corresponds to the FormModel, which triggered the event.
FormFix uses the ReadDataItem event to try to read in any information that it may have previously written out in the WriteDataItem events. Application code can handle the ReadDataItem events by reversing the process of the WriteDataItem events. For instance, when an Accusoft.FormFixSdk.IdentificationProcessor triggers the event, the application code should search the OtherDataItems collection of the FormSet object for a DataItem with the Type value specified in the ReadDataItem event arguments. If a matching DataItem is found, then the event handler can pass the Content string back to the IdentificationProcessor through the event arguments.
Also required with handling of the ReadDataItem events is handling of the ReadChecksum events. These events need to be handled to provide FormFix with a checksum for the form set or for a specific form model. FormFix uses these checksum values to determine if the DataItem content read in the ReadDataItem events is current with the form set or form model. If this is not true, then the DataItem content cannot be used. For this reason, the checksum value provided to the ReadChecksum events should be calculated based on the content of the form set or of a form definition’s template image. The FormDirector API provides methods which can be used to calculate the values that are provided to the ReadChecksum events.
The event handler of an Accusoft.FormFixSdk.IdentificationProcessor.ReadChecksum event should use the Accusoft.FormDirectorSdk.FormSet.GetTemplateHashCode method to generate the checksum value.
The event handler of an Accusoft.FormFixSdk.FormModel.ReadChecksum event should use the Accusoft.FormDirectorSdk.FormDefinition.GetTemplateHashCode method to generate the checksum value.
The Accusoft.FormFixSdk.FormModel class is required for use of the form identification feature of FormFix. The FormModel class allows calling code to load the image of the form into memory only when it is needed. This is done through the Accusoft.FormFixSdk.FormModel.ReadFormImage event. A handler for this event should get the template image of the FormDefinition from the TemplateImages collections, create a new Accusoft.FormFixSdk.FormImage object, and pass it back to the FormModel through the event arguments. The following code demonstrates this.
Example |
Copy Code |
---|---|
private void FormModelReadFormImage(object sender, ReadFormImageEventArgs readFormImageEventArgs) { // ... get FormDefinition ... readFormImageEventArgs.FormImage = FormImage.FromHdib(formDefinition.TemplateImages[0].Hdib, true, myFormFix); } |