The Reports for WinForms assembly now provides two distinctly different methods for generating reports:
? Using the C1PrintDocument.ImportC1Report method.
? Using the C1Report component.
While many existing reports can be correctly generated using either method, there are some important differences between the two. Some of the key differences are listed below.
Data binding:
The ImportC1Report method creates a data-bound C1PrintDocument component. The C1PrintDocument component is then generated with data being fetched. The resulting document can be refreshed with data refreshing. When the C1Report component is used, the generated document already contains embedded data fetched during document generation, and the resulting document is not data-bound (but of course, the report can be rendered again, refreshing the data).
Document structure:
When a report is imported in the resulting C1PrintDocument structure, all fields are represented by RenderField, and all sections by RenderSection objects. If a report definition contains groups, each group is represented by a RenderArea object, with nested RenderSection objects for the group header and footer, and a RenderArea for the nested group.
When the C1Report component is used, each report section is rendered into a RenderArea object. The fields are rendered as follows:
? If LineSlant is specified, a RenderLine is generated;
? If image or barcode is specified, a RenderImage is generated;
? If RTF is True, a RenderRichText is generated;
? In all other cases, a RenderText is generated.
Page size:
When a report with unset (or set to zeros) CustomWidth and CustomHeight properties is imported on a system without a printer, the default page size depends on the locale, as always in C1PrintDocument (for example, for US and Canada, the page size will be Letter, for Russia A4, and so on).
When such report is loaded into the C1Report component, the page size is always set to Letter (8.5 x 11 inches), which is the behavior of C1.Win.C1Report.C1Report.
Default printer:
On a system with one or more printers installed, the default page size for an imported report is determined using the same logic as for a regular C1PrintDocument (in particular, the MeasurementPrinterName property is used to determine which printer to use). The main reason for this behavior is to avoid long wait times on systems with default network printers. When the C1Report component is used, the default page size is determined by the system default printer.
Limitations of import:
The import method has some inherent limitations which are not likely to ever be lifted. These limitations include:
? When import is used, the C1Report object model is not available and report events are not invoked. Hence the main limitation of import: reports depending on C#/VB event handlers cannot be rendered correctly when imported.
? Scripting limitations:
o C1PrintDocument object: - The Font property is read-only.
o Field object: - Section, Font, and Subreport properties are read-only; - LineSpacing, SubreportHasData, and LinkValue properties are not supported; if the LinkTarget property contains an expression, it is not evaluated and will be inserted into the generated report as-is.
o Layout object: - The ColumnLayout property is not supported, columns always go top to bottom and left to right. - LabelSpacingX, LabelSpacingY, and OverlayReplacements are not supported. - ForcePageBreak cannot be used in the OnPrint handler.
? The dialog box is not shown for parameterized reports. Instead, default values depending on the parameter type are used (0 for numbers, empty string for strings, the current date for dates and so on).
? PageHeader/PageFooter cannot reference database fields.
? In multi-column reports, the report header is printed only above the first column (in C1Report, the header spans all columns).
? Left to right orientation for columns is not supported – columns are always oriented from top to bottom.
? In C1Report, a Field containing an image, with CanGrow set to True and PictureScale set to Clip, has the width equal to that of the image. When imported, the width of such a field is scaled proportionally to the width of the image.
Deciding on Report Generation Method
Because two ways of generating reports are available (using the C1Report component vs. importing the report into a C1PrintDocument), you may ask, "Which method is preferable?" Our recommendations are as follows:
? If any of the limitations of import (see Generating Reports (C1Report vs. C1PrintDocument) for a list of limitations) are critical to your application, use the C1Report component.
? If you are a user of a previous version of C1Report and are not familiar with the C1PrintDocument object model, you may still continue to use the C1Report component provided by C1Preview.
? If, on the other hand, you have some experience with C1PrintDocument, or are starting a new project, using import is the preferred approach, due to the following considerations:
o C1PrintDocument integration: when a report definition has been imported into a C1PrintDocument, the resulting document can be manipulated as any other C1PrintDocument. For example, user code can add content to the document body, modify document properties, and so on. Such changes will persist even when the document is refreshed.
o Some problems existing in C1Report are solved by import; specifically, in C1Report side-by-side objects cannot be correctly split between pages, and borders are not rendered correctly on objects split between pages. Neither of these problems exists when a report is imported into C1PrintDocument.
o Import is slightly more efficient both memory- and speed-wise.
o Future enhancements: it is likely that some future enhancements will affect only import. |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图
