Input Items
Screenshots and diagrams on this page illustrate the historical desktop tools or conversion workflow; installed versions may look different.
The PPJ Framework uses a .NET data set to pass data between the application and reports (for more information about the internal architecture, see Passing Data). The data set contains two tables, called InputItems and ReportVariables. All input items and report variables will appear as fields below these two tables in List & Label as shown in the following screenshot:
Field list with Input Items and Report Variables in List & Label
All Report Builder source data types are supported and will be transferred to the target report. Since List & Label has a similar architecture compared to Report Builder, the data set is not filled up front but passed record by record. The adapter can deliver records incrementally, but grouping and variable-update timing still require comparison with the source application.
In order to extend the report with new fields, open the data set definition (xsd file) and add a field with one of the data types as shown in the following table:
| Report data type | .NET data set type |
|---|---|
| String | String (xs:string) |
| Number | Decimal (xs:decimal) |
| Date/Time | DateTime (xs:dateTime) |
| Object | Byte[] (xs:base64Binary) |
The field can then be added to calls such as Sal.ReportPrint() in the converted application.
List & Label doesn't store data type information about data fields, only the field name is saved in the report. Therefore it is necessary to deploy the data set always with the report. The PPJ Framework uses the xsd file to pass input items and variables properly with the correct data type.
Extending the Contract
For example, adding an OrderReference input requires three matching changes: declare the field in the XSD, reference that field in the report, and supply its value from the application's report input list. Test an ordinary reference, a missing optional value, and a long reference that can wrap. A designer preview using sample data checks the report layout; it does not prove the migrated application supplies that field.
Keep the XSD field name and type, report expression, and application input list in sync. Test nulls and missing optional values as well as ordinary values. Adding a field to the designer alone does not make the application supply it. Deploy the revised schema and report together.