In order to conserve memory, especially when working with a large number of templates, FormFix relies on an event system to acquire much of its data.
Two FormFix objects expose events:
| Object | Events Exposed |
| FormModel |
|
| IdentificationProcessor |
|
The above events support three types of data:
One of the simplest interactions occurs during drop-out processing. Drop-out works by comparing a filled image to a template image. The filled image is a parameter to the CreateImageOfField method, but there is no template image. Instead, you provide a FormModel object and FormFix relies on that object to acquire a template image.
The sequence diagram below shows two drop-out operations. In the first drop-out operation, the FormModel object does not have a template image, so it must request one. When it requests a template image, it saves a copy internally. In the second drop-out operation, the FormModel object already has an internal copy of the template image, so it can return it immediately. Your application must handle the ReadFormImage event and it will normally rely on the FormDirector component (as shown) to acquire that image.
Form Dropout
A RegistrationProcessor object will operate much the same as a DropOutProcessor object, relying on a FormModel object to provide a template image when needed.
The events raised during form identification are much more complex because form identification will raise events on an IdentificationProcessor and one or more FormModel objects. In some cases, it will raise all four FormModel and all three IdentificationProcessor events. There are also several different modes of operation, while drop-out only has two (template image is not cached).
The sequence diagram below shows the sequence of events for a "normal" run of form identification. Note that the events involving the FormModel object will be repeated, once for each FormModel. This diagram shows two form identification operations. The first one causes the IdentificationProcessor to load the checksums and analysis results. The second identification operation relies on the data that the first operation loaded.
In order to function properly in this case, your code must handle the following events:
Normally, you should let FormDirector handle the requests as shown in the diagram below.
Identification
The above diagram is accurate if FormFix has already analyzed each FormModel and the set of FormModel objects, successfully saved the result of that analysis, and the form set has not changed since that analysis. That will not always be the case and the next two diagrams delve deeper into event handling in other cases.
The most common exception to the diagram above is the very first run of form identification, where FormFix has not yet analyzed the template images or the form set.
The sequence diagram below shows how FormFix will analyze a template image and save the results. The sequence focuses on the ReadDataItem event, which was shown in the diagram above, except that in this case no data item is present in the form definition file. Instead, formFix will request a copy of the template image, analyze it, save the results to the form definition file, and return the result of the analysis to the IdentificationProcessor.
One other case merits mention here because it is not uncommon and the events are nearly identical. When it creates the data item holding the result of template analysis, FormFix includes the checksum that the ReadChecksum event returned. If you change your form definition in some meaningful way (in particular if you modify the template), the checksum of the form will not match the checksum in the data item and FormFix will automatically reanalyze the template image and re-save the data item.
Form Model Analysis
Like form models, the IdentificationProcessor will need to analyze a form set if it has not already analyzed it and successfully saved the result of that analysis, or the form set has changed since that analysis. The sequence diagram below shows the events that the IdentificationProcessor raises when a form set has not yet been analyzed.
To properly handle this event, you simply need to handle the WriteDataItem event and save the data item to the location that the ReadDataItem event expects to find it. Normally, you will save the data item as an independent entry in FormDirector's FormSet.OtherDataItems collection.
Again similar to handling of form models, the IdentificationProcessor will automatically detect changes to the form set using the checksum and regenerate the data item if necessary.
Form Set Analysis