filters

The filters object is designed to run filters against text data. Both standard and custom filters can be defined in the Image Manager's Custom Code window. The goal of each filter is to process text data and modify it in some way so that it is more useful. A filter could be as simple as something that formats a raw number into a nice text format, or strips out non-digit characters, or even manipulates line item detail to organize it into proper columns and rows.

Filter definitions are found in the im/filters.ini and im/filters.custom.ini files. Each filter is in a section, headed by the name in brackets. Each section contains a description= line, an optional parameters list, and an optional types list. The types list contains a comma-separated list of field types this filter can apply to, to provide context when looking up filters in job design. Types can include zone types ocr, bcd, grid, col, and field types text, note, number, date, list, and lookup. A filter can be run by code regardless of the types= list. The balance of the filter section is code designed to convert the value in$ to the value out$ upon execution with the run() or run$() methods.

Filters can use parameters, passed into the running code as part of the name or as an array. Parameters can be passed to filters explicitly in an associative array param$[all] (i.e. p$["Val1"]="Value 1", passed as p$[all]), or via a syntax convention in the name (i.e. filteritem(Val1="Value 1",Val2="Value 2") - note quotes are optional if commas are not in values). If a named value is passed both via parenthesized argument and parameter array, the parameter array value is used.

Image Manager jobs use filters in various places, where the design calls for it. Custom code can also use filters, as the filters object is available to any code the UnForm server runs.

errmsg$, lasterrmsg$ can be set by filter code to indicate an error condition.

doc contains an inbounddoc object when the filter is run in the context of an image manager job, or an docflowdoc object when run from a docflow job.

Run(name$,in$,out$[,param$[all]]) runs the filter name$ with a value supplied as in$. It expects the filter to create out$. Optionally pass a param$[all] associative array with parameter names as keys, or use the name syntax described above. The method returns true (1) if the errmsg$ variable is null.

Run(docobj,name$,in$,out$[,param$[all]]) runs the filter name$ with a value supplied as in$. It expects the filter to create out$. Optionally pass a param$[all] associative array with parameter names as keys, or use the name syntax described above. The docobj should contain an inbounddoc object or a libdoc object that has been pre-instantiated. This is an alternative to setting the doc property. The method returns true (1) if the errmsg$ variable is null.

Run$(name$,in$[,param$[all]]) runs the filter name$ with a value supplied as in$. It returns the filter code's out$ value. Optionally pass a param$[all] associative array with parameter names as keys, or use the name syntax described above.

Run$(docobj,name$,in$,param$[all]]) runs the filter name$ with a value supplied as in$. It returns the filter code's out$ value. Optionally pass a param$[all] associative array with parameter names as keys, or use the name syntax described above. The docobj should contain an inbounddoc object or a libdoc object that has been pre-instantiated. This is an alternative to setting the doc property.