cObject
---Report
------Report_DS
---------BasicReport
------------cWinReport2
------------WinReport
The BasicReport class supports creation of hierarchies of objects that can output data from the database or change large numbers of records in it. Objects of this class support all types of constraints including parent-table, full access to indexes with multi-level subsection totalling, access to child-table records by parent-table indexes, and complete control of pagination. They are capable of using the database services (finding, deleting, saving, constraints) of data-dictionary objects.
This class provides display of a Working message, a Cancel/Continue interruption option, and a prompt for end-of-screen. It also supports the maintenance of a status-log file for progress reports and/or errors that arise during unattended (batch) operations.
BasicReport objects will not work inside scrolling containers (cScrollingContainer, cDbScrollingContainer). If you need to have a ReportView with scrolling containers for a large number of report selections, place the BasicReport object insid ethe ReportView, but outside the scrolling containers.
The BasicReport class uses a number of commands created for use by this class and its subclasses. Those commands are:
Use DfRpt.pkg Object ReportName is a BasicReport Report_Main_File MainTableName Function Starting_Main_Report Returns Integer Integer iRetVal Integer iIndex Forward Get Starting_Main_Report to iRetVal Get piSortIndex to iIndex Report_Index by iIndex // set the sort order Sysdate Footer.1 // set date for report Function_Return iRetVal End_Function Procedure OnConstrain Constrain Vndr.Status eq 'A' Forward Send OnConstrain End_Procedure Procedure_Section SectionName Print ... : Output_PageCheck End_Procedure Procedure_Section ... : End_Procedure End_Object
This class supports creation of objects for outputting data from or modifying data in, the database. When used with DDOs, they can also support batch updating of the database. They can also be used with DDOs where it is desired to make use in the report of business rules for the table(s) in question that are embodied in existing DDOs and subclasses.
This class produces report objects with all the facilities commonly needed in reports. This includes a display on the screen to show at all times while the report is running, that it is running. The same display offers a means to interrupt the report (a keypress), and upon being interrupted, then offers the options to abandon the report or to resume it. To support unattended operations, this class supports a status-log file for error reports and/or status messages that are generated during the unattended process.
Objects of this class can, and should, be nested for any of a variety of special requirements, such as conditional execution of reports, use of an index of a parent table with records of a child table, multiple executions of reports and so on. Nesting one report within another automatically constrains the records selected in the nested report's (child) table to those related to by the record in the outer report's (parent) table buffer.
The internal syntax with which this object is defined is closely patterned after that used with the predecessor DataFlex Report Macro, which this class replaces. All the capabilities of the Report Macro are supported in this class, along with many additional ones. This object uses several, but not all, of the global variables maintained and used by the Report Macro.
Finally note that if this object has no server assigned to it, all of the record finding will be handled by the report instead of the DSO. While it is theoretically possible to mix DDO and non-DDO reports in a nested report structure, this is not advised.
This class uses output images, unlike GUI report classes. Its output is always in a single mono-spaced font. It cannot output to the screen or the printer directly; all output must be to a file for later printing or display. It can format output for any output device.
Objects of this class should be encapsulated in a manner similar to that recommended for views (groups of DEOs), and accessed in a similar manner (through global messages). A program may have as many report objects and report "views" in it as desired.
The following commands are used by BasicReport:
Thesa are obsolete commands. You should use the OnConstrain event in its place
This is the same as the command used by DDOs. It is essentially a command of convenience. It gives you a place to place your constraints while ensuring that any built-in constraints (nesting constraints) are respected. You could actually write a constrain procedure which would accomplish the same thing. These two examples are identical:
Begin_Constraints Constrain Vndr.Status eq 'A' End_Constraints Procedure OnConstrain Constrain Vndr.Status eq 'A' Forward send OnConstrain End_Procedure
Because the begin_constraints-end_constraints commands actually create the constrain procedure, you cannot place both a begin_constraints-end_constraints and a Procedure OnConstrain in the same object or class.
This outputs the image represented by image_number. This command is used by the output_imageNum procedure.
This command does a remaining-page-space check and then outputs image, if specified or, if not, the image specified in the preceding procedure_section command. If there is insufficient space left on the page for image or (if specified) lines, a new page will be started. This command will almost always be placed inside a procedure_section.
When no parameters (image [lines]) are passed, the image that was named in the procedure_section command will be output. If no lines height was specified, the pagecheck will be based on the length of the image. This will be the most common usage of this command. If a lines height was named in the procedure_section command, the pagecheck will be based on that length.
Note that there is an output_pagecheck command and an output_pagecheck procedure. When the command is expanded, it sends the message. The command was created to make the Report Package easier to program.
This command performs a pagecheck and an output on an image that contains a print_wrapped field. The wrapped fields will be word-wrapped and printed in as many lines as is required to print the entire text. A field that is print-wrapped is created by using the DataFlex print_wrap command. Page breaks will be handled as they are needed. Note that an image is required with this command.
This command defines the start of a procedure section. It is similar to the predecessor Report Macro's section command. The procedure_section command allows you to:
Section_name must be one of the following keywords. Each of these is described above in the section on Procedures:
Page_Top
Report_Header
Page_Header
Page_Title
SubHeader_Init1..n
SubHeader1..n
Body
SubTotal1..n
Total
Page_Total
Page_Footer
Report_Footer
Page_Bottom
If the as image parameter is not used, then the command will use an image named section_name (i.e., procedure_section body will attempt to use an image named body). Since the Report Package supports multiple report objects per program, you are advised to always use the as image option.
If the as image option is not used and there is no Image section_name, then no image is defined, and this command acts the same as a procedure command. This is valid and is often used with subHeader_init procedure sections and any section that is not image-based.
The procedure_section command is a command of convenience. You could gain the same functionality with a procedure command with some extra commands. For example, these two examples are actually identical:
Procedure_Section Body as VndrBody forward send body Print Vndr.Name Output_PageCheck End_Procedure
Procedure Body Integer Output_Lines OutPut_Image forward send body Move VndrBody.LINES to Output_Lines Move VndrBody.N to Output_Image AutoPage VndrBody Print Vndr.Name Output_PageCheck End_Procedure
This example should also explain how the output_pagecheck command works with no parameters-it uses the values of the local variables output_image and output_lines.
In the above examples, the output_pagecheck statements could have been replaced with either of these two statements:
output_pageCheck vndrbody.N vndrbody.Lines output_pageCheck output_image output_lines
This command defines the breakpoints needed in a report and is the same as using the break parameter in the report object-creation statement. The report_breaks command is the more-flexible approach because it may be used in class construction. In addition, when using the break parameter, you cannot define a break that is a function local to the report object you are creating. This doesn't work:
Object aReport is a basicReport Break (aFunction(Self))
This does work:
Object R is a BasicReport Report_Breaks (F(self))
The breakpoints can be just about anything. They can be a table.field (as in the Report Macro), they can be a variable or a window, or they can be a built-in or a user-defined function.
Report_Breaks (Left(Vndr.Name, 1)) Vndr.Name Report_Breaks (G_Func(Desktop, Vndr.Id)) Report_Breaks (L_Func(Self, Vndr.Due))
The report_breaks command actually creates a custom function named test_breakpoints. Therefore, when used in a class, the report_breaks command must not be placed in a procedure or function, but should be placed directly inside the class. The following example shows how a basicReport subclass should be created using the various report_???? commands.
Class V_Report is a basicReport Report_Breaks (left(Vndr.name, 1)) Vndr.Name Procedure Construct_Object Forward send Construct_Object Report_Main_file Vndr Report_Index by Vndr.Name End_Procedure : End_Class
This command determines which DDO will serve this report object. It does this by setting the server property to the DDO's object ID. The server property may also be set in the report object's creation statement with the using option, or it may be set by setting the server property.
The following examples are all identical:
Object VndrReport is a basicReport Using (Vndr_DS(self))
Object VndrReport is a basicReport Report_Data_Set (Vndr_DS(self))
Object VndrReport is a basicReport Set Server to (Vndr_DS(self))
This command sets the index of the main_file to be used by the report and the direction the index should be traversed. It does this by setting two properties: ordering and find_down_state. This may also be accomplished by placing this command's parameters in the report-object-creation statement, or by directly setting the properties.
The report_index command is the most-flexible approach because it can be used inside of class construction and it can used with either an index number or with a table.field whose main index should be used.
Report_Index BY 2 Report_Index DOWN Vndr.Name Report_Index BY IntVar
If the report_index command is used in a class, remember that it must be placed inside a procedure or function (most likely Procedure construct_object). Also note that this command (and the associated properties) may be used and changed at runtime.
This command determines the main table for a report. It does this by simply setting the main_file property to the df_filename's filenumber. This property may also be set by the report object's creation statement with the main_file file_name option, or it may be set by setting the main_file property.
The following examples are all identical:
Object VndrReport is a basicReport Main_File Vndr
Object VndrReport is a basicReport Report_Main_File Vndr
Object VndrReport is a basicReport Set Main_File to Vndr.File_number
The report_main_file command (or setting the main_file property) are more flexible than the command-line main_file option because they can be used in both object and class definitions.
If the report_main_file command (or a set main_file ... statement) are used in a class, remember that it must be placed inside a procedure or function (most likely Procedure construct_object). Also note that the main_file property may be set and changed at runtime.
This object does not zero sub-totals before a report is run. This means that if you cancel a report in the middle and restart without leaving the program, the subtotals may be wrong. Zero_subtotals zeros the subtotal accumulators of all image windows named. This command should be executed as part of a report's initialization, possibly in the starting_report function. It is a good idea to zero the subtotal accumulators of any image that uses a subtotal. You can find all subtotals by doing a search of your program for all subtotal commands.
Function Starting_Report Returns Integer Zero_SubTotals SubTotal2.2 SubTotal2.3 SubTotal1.2 Zero_SubTotals VndrTotal VndrDue VndrPaid End_Function