Report Analysis

In the process of designing reporting to meet the needs of your users, one question is a major determinant in the direction that you will follow: Are you replacing an existing system or creating a new one? If the latter is the case, your task is much simpler to accomplish. The system's users and the information that they desire from the application will define the output. They will not come to the design process with a predetermined bias towards a favorite report or a fixed way of doing things and they will be more open to exploring online information in place of more printed matter.

When your application is replacing an existing system, you still want to arrive at the same destination. Unfortunately your path may be a litt le less clear and a little more difficult as users lobby for their favorite list ings. Your biggest design task is going to be to examine the current report output with an eye towards redundancy and need. Users may be hard pressed to explain why a specific report is necessary to accomplish their job; they only know that this is the XYZ report and that they have

Chapter 7-Reporting and Printing

always used it. Your task is to comprehend what the reports are presenting and explain, if possible, how the report can be deleted and replaced with another information source. Tell the users that multiple reports are redundant, determine if two or more reports can be rolled into a single output, inform them that the output of a certain report is meaningless in the current or future environment. Since you are doing this in the initial analysis phase of your project, you are also in a position to explain that some simple summary reports can easily be replaced by an online query that provides dynamic information at their fingertips, when needed. With their agreement, an interactive reporting module can be built into the program rather than added later, and the user can "pull" data from the application rather than having it "pushed" at them.

During the report analysis phase, you are seeking to answer three questions:

  1. In analyzing the data that is to be collected, can all of the user's information requests be satisfied?
  2. If the application is replacing an existing system, what is the utility of the current reports? Can they be combined or deleted for greater efficiency?
  3. Is hard copy output really the best way to answer a question?

The answer to the first query may send you back to the design table with your data structures, adding or deleting some facts that had previously seemed important. The second and third questions open up more fertile design possibilities. Not only will the reports come under scrutiny for efficiencies and usefulness, but the application that wraps them will also be considered. Your analysis may point to pieces of the program that would benefit from being reworked.

Once a decision has been reached as to elimination, combination, simplification, etc., in the reporting scheme, analyzing the reports themselves takes a different eye. Your initial query will be to frequency. How often does this information get produced? Is it produced infrequently, in a manner that suggests an ad hoc query would be an improvement, or does the report get printed so often that the usefulness of previous editions still exists while the daily copies go into the recycling pile? Examine the distribution of the report to determine who receives it and why Again, examine the recycling bin in the user's area for clues. Efficacy is the last consideration of the report. In reviewing each report or information request, consider the following points:

214 ■ fartiI—The Delphi Database Tools u What is the amount and level of detail?

  • What decision-making capabilities does this affect?
  • What is the degree of accuracy required from the report and can the data collected support it?
  • IS the information presented clearly or does the user draw up a summary just to interpret the original report?
  • is the appropriate format being used? More detail, less detail? Cross tabulation?
  • IS the key information that justifies the report buried on multiple pages or summarized on the top of the report where it can be easily found?
  • Does the report or information request satisfy the need for which it was designed or requisitioned?

Playing this game of twenty questions can be time consuming and it is easy to find yourself in the middle of a holy war over the need for a specific piece of reporting. Forge on; the payoff in the productivity and value upside exceeds the downside of ignoring the analysis or prod uc ing standard reports by a wide margin.

So what then are the measures of a good report? The overriding response to that question is that the report has a significant bearing on the operational goals of the user or department receiving it. Addition& success factors include:

  • The report compares actual results to a goal so that the user can quickly determine their operational efficiency.
  • Only essential information appears on the report so that the user can quickly assimilate it and come to a decision.
  • The information on the report is in the user's language. They should never have to translate or summarize the figures or other information in order to use it.
  • Trends on the report should be crystal clear. Again, the user should not be producing trending reports from your reports in order to utilize the information.
  • Get to the point! Nice to have and other extraneous information should be saved for other reports or, better yet, discarded altogether;

Use a critical eye and an analytical frame of mind during the report analysis phase of your project and you will quickly be able to weed out the offenders in your efficiency quest. Think differently from the users on your design committee. A manager will often frame things in terms of accomplishments, for example, cost reductions, Why not produce a

Chapter 7-Reporting and Printing ■ 215

report that shows cost increases? It would be much easier to understand a rapid increase in costs than to assimilate a reduction in the rate of cost decreases.

Report Formats

The formatting of reports can be generalized into four recognizable categories: columnar reports, forms, production labels, and cross-tab reports. You may discover more exotic forms in your work but we'll use these as a baseline for discussion.

Columnar reports are easily the most familiar form to you and your users. These are traditional multiple-row listings of data usually reporting all or an important subset of the user's data. The rows are tabulated and grouped to produce information that is important to the user. A regional listing of all of the firm's clients would be a good example of this type of report.

Forms are ubiquitous in the business world but many users and developers fail to consider them as reports. A form usually reports one record at a time and formats it in a highly readable layout that conforms to a preprinted form. The form is also commonly used to report master-detail information. An invoice, for example, shows the client address and credit information as well as all of the services performed for the reporting period.

Production labels are not limited to mailing information but also include package and warehousing information. Labels can often serve multiple reporting purposes. A label may initially serve as a pick ticket for a customer order that later translates, when stuck on a shipping form, as the basis for an invoice.

Cross-tabulation reports will be most familiar to spreadsheet users. The ability to arrange data so that columns and rows meet and produce information at the intersection is one of the strengths of the electronic spreadsheet. Users will often discover new trends and uses for data when it is presented in this form.

Being familiar with the different forms that information can take when output to paper can make your advice of much greater value to your users. Listening to the needs of your application's users will enable you to steer them towards the most beneficial format for their reports. Showing a user how a report that they have used for years can be transformed into an important competitive tool by selecting the appropriate format can often make or break their positive impression of your application.

Chapter 7-Reporting and Printing ■ 215

Producing the Reports

Once the format has been defined, the developer is left to select the best method of programming and producing the report. Choosing between traditional hand coding and component-based methods is one of the primary decisions. This often comes down to a measure of the quantity and style of output required compared against the effort and overhead necessary to implement the programmatic solution. Simple text and formatted database reports are sometimes more expeditiously handled by the manual manipulation of the Windows printer functions rather than the multiplicity of components and their associated overhead.

Using the TPrinter Object

Before approaching the Delphi object directly, a brief discussion of printing in Windows will lay a sound foundation for understanding what Delphi wraps. Printing in Windows is handled by the graphical device interface (GDI). The procedure for outputting text and graphics on a printer device is very much the same as that used for displaying text and graphics to a video output device. The program will retrieve a, handle to a device context and then direct the desired output to that device. The device context is Windows' method for ensuring device independence.

Your application does not need to know any of the specific commands required by the printer to which it is directing output. Instead, it calls high-level functions from the GDI that then convert these commands into low-level device instructions specific to the output device. When the application sends output to a printer device context, Windows activates the print spooler to manage the print request. The print manager provides six functions for use in controlling the print job as shown in Figure 7.1.

Function

AbortDoc

Purpose

Terminates a print job.

Function

AbortDoc

Purpose

Terminates a print job.

EndDoc

Ends a print job.

EndPage

Ends a page.

SetAbortProc

Sets the abort function for a print job.

StartDoc

Starts a print job.

StartPage

Prepares the printer driver to receive data.

Figure 7. I The printer spooler functions

Figure 7. I The printer spooler functions

TPrinter is the Delphi class that encapsulates this printer interface. Within the Printers unit, the variable Printer is declared as an instance of TPrinter, ready to be called. 32-bit Delphi instantiates a global object of class TPrinter that is local to the printer unit relating to the addition of the function SetPrinter, which can change the global object. The properties of the TPrinter class are shown in Figure 7.2.

Property

Default Value Purpose

Property

Default Value Purpose

Aborted

When True, the print job was aborted by the user.

Canvas

This represents the surface of the currently printing page. _

Capabilities

This property contains the capabilities for the current printer. It contains information on the orientation, number of copies, and if the report is to be collated.

Copies

Specifies the number of copies to be printed.

Fonts

Contains a list of the TrueType fonts supported by the printer.

Handle

The Windows handle for the printer object.

Orientation

Determines if the print job is printed in Landscape or Portrait mode.

PageHeight

This is the height of the currently printing page, measured in pixels.

PageNumber

Indicates the page that is currently printing.

PageWidth

This is the width of the currently printing page, measured in pixels.

Printer-Index

The index value of the currently selected printer from the Printers property.

Printers

A list of all of the installed Windows printers.

Printing

A Boolean variable indicating the current print status (printing or not).

Title

The document title that appears in the print manager or on network header pages.

Figure 7.2 The TPrinter class properties

The key property of the TPrinter class is Canvas. The canvas of the printer is utilized in the same fashion as the canvas of a form. Text and graphical output is directed to the printer canvas from which it is converted to printer commands and sent to the device. To utilize Canvas and begin a print job, the developer calls the printer's BeginDoc method, opening the canvas surface to receive output. All of the Canvas related methods are then available to the program to format the output as

desired. When a page of output has been laid out on the canvas, the printer's EndDoc method is used to send the canvas' output image to the printer. The Abort method can be called to discard a print job once trans. ferred to the print manager. The NewPage method alternately will send output to the printer and start working on a new canvas page. The methods used to format the output on the canvas differ in their abilities. To present the methods in context, their presentation will be in order of declining precision with regard to the placement of text on the canvas.

Before continuing the discussion of the specifics of text placement, important differences in usage of the Canvas of a print device and that of a video device should be noted. Output location coordinates for printed output lie along a plane that is much more dynamic than that of a video output device. Changing the resolution for the application's carefully designed printed output can happen as quickly as the user can switch from the network laser printer to her local line printer or fax software. X and Y on the laser printer plane will not fall in the same spot on lower resolution print devices such as the line printer. Hard-coded output coordinates will produce poor output and no scroll bars will appear on the document to allow the user to access the missing data as they would on a screen form. Windows eases the task of managing the dynamic environment by returning the information needed about the capabilities of the device through its device context. Specific information such as pixel measurements can be retrieved through a call to the API function GetDeviceCaps. A specific example of calling the function with a device context and an enumerated constant will be demonstrated in an upcoming example.

The best way to begin our exploration of manual print control is through some simple, non-database examples that build up to the production of a database report printed strictly through the Delphi code. The first example will print text lines to the printer canvas using the canvas' TextOut method. TextOut requires three parameters when called: the X and Y pixel coordinates for placing the text string and the text string itself. The code below demonstrates a simple procedure to send text to the printer.

implementation uses Printers;

procedure TForml .ButtonlClick (Sender: TObject); begin

Printer.BeginDoc;

Pr inter. Canvas .TextOut ( 10, 10, Printer.EndDoc; end;

implementation uses Printers;

procedure TForml .Button lC lick (Sender : var

Outline : string;

centerpoint : integer ;

begin

Printer.BeginDoc;

outline := 'Text 1 ine to be centered.'; centerpoint := (Pr inter .Pageffidth div 2) -

(Printer.Canvas.TextWidth('A') * (Length(outline)

Printer .Canvas .Tex tOut (centerpoi nt, 10. outline); Printer.EndDoc; end;

Pr inter. Canvas .TextOut ( 10, 10, Printer.EndDoc; end;

The power of the TextOut method lies in its ability to precisely place the output at a desired location on the document through the X and Y coordinates. Consider the placement of a centered report title. To provide the proper starting location to the TextOut method, you must do some simple calculations with the call or prior to it. Centering text on the printed page is demonstrated in this snippet:

implementation uses Printers;

procedure TForml .Button lC lick (Sender : var

Outline : string;

centerpoint : integer ;

begin

Printer.BeginDoc;

outline := 'Text 1 ine to be centered.'; centerpoint := (Pr inter .Pageffidth div 2) -

(Printer.Canvas.TextWidth('A') * (Length(outline)

Printer .Canvas .Tex tOut (centerpoi nt, 10. outline); Printer.EndDoc; end;

To determine the center of the canvas surface as defined by the printer interface, the PageWidth property is queried. This property contains the width of the currently selected printer page measured in pixels. This value is divided in half to determine the approximate centerline of the page. A pair of sub-calculations provides the center of the text string. The TextWidth method of Canvas provides the width, in pixels, of the string data passed to it. In the example, the function is passed a single character and returns a base width value per character to use as a basis for computing the length of a full line of text. The base value is then multiplied by half the number of characters in the text line to be printed. This equation returns a factor in pixels which, when subtracted from the center point of Canvas, gives a starting point to the X parameter of the TextOut method.

Was this article helpful?

0 0

Post a comment