and fills out a PDF based form system
Retrieves the next address of all semantically well defined address defined by the currently loaded PDF file.
Note, that basically the index of the address struct and the occupation status (defined or not) is returned , and not an IAddress interface. Based on the returned status, an address can be set or overwritten by the AddAddress method using the given bstrAddressName variable.
Furthermore, the method returns a possible non-empty constraint, that supplies further specific information about the requested data. The constraint must be seen either as >xsd:appinfo< element holding information for the main software or as >xsd:annotation< formulated in the natural language of the form requesting specific information. Example of ist usage are:
VARIANT_FALSE is returned if the end of the address list is reached.
|C/C++ calling syntax|
|HRESULT GetNextAddressRole(|| AddressRoleType
|Calling argument description|
|[out] AddressRoleType||*peAddressRole||The semantic typification of the address defined by the AddressRoleType enumerator.|
|[out] BSTR||*pbstrAddressName||The PDF internal variable name/placeholder onto which the address was mapped.|
|[out] long||*plIndex||The '0'-based index into the array of addresses of the given address role type.|
|[out] long||*plMaxOccurs||The maximal cardinality of this given address role type|
|[out] YesNoType||*peIsDefined||Boolean that designates if the address is already preset and defined (enYes) or not (enNo)|
|[out] BSTR||*pbstrConstraint||bstrConstraint is -if defined at all- a constraint onto the value space, a constraint of the time axis (appinfo machine instruction) or a natural language based instruction (annotation). The constraint of an address is formatted by using/defining variables of the corresponding AddAddress method (without any IAddress participation!) and setting/assigning a constraint value. These token=value sets are whitespace separated, case-insensitive and the notation is exactly as in the API documentation.
Furthermore, there are situations where a constraint of the value space is defined by the applicable law. Therefore, the aforementioned token=value set can optionally be augmented by a eLawType set, e.g. eLawType=enUVG for setting focus to the UVG law (cf the enumeration space of eLawType for the possible set of values!).
In fact the eLawType constraint is the only important constraint if addresses are concerned and should be implemented at a minimum.
For example an insurance address is requested in the form "birth notice" (covered by KVG 64/KVV 105). From a logical point of view, it is clear that a KVG insurance address is requested. However, only by setting the constraint:
Please note, that the constraint is not enforced by the COM module to allow other data as well - in that sense, it is more a hint than a constraint. However, it does not make any sense e.g. to add an UVG address in the aforementioned form!
|[out, retval] VARIANT_BOOL||*pbStatus||Return status of the method. If pbStatus is VARIANT_FALSE the end of data is reached|
|C/C++ return value|
|S_OK||This value is returned if the function call was successful or if the return value of a boolean method signalling a true value. In this case the VARIANT_BOOL is set to VARIANT_TRUE.|
|S_FALSE||This is the return value of a boolean method signalling a false return value. In this case the VARIANT_BOOL is set to VARIANT_FALSE.|
|E_name||This value is returned if the function call was unsuccessful and an error exception was generated. Note that if you are using SmartPointers an exception is thrown under these conditions.|