Crosstab Presentation Style

If not for this presentation style, you end up writing hundreds of lines of
code in the PowerBuilder application, or the DBA has to write huge stored
procedures. Let's say the "trans" table has the following data.

Say for example you want to print a report that lists all the products and
quantity issued each day. That means, you list all the products one per
each row, and list the dates horizontally. Remember, each month has
different number of days, 28, 29, 20, 31. ( 20 is not a mistake, if the
report is generated on 20th of a month, then the report should list dates
only till 20th ). That means you need to paint four reports and use the
appropriate one depending on the month. To print only those dates in the
heading for which there is data is really a tough job. Let the report you
want look like:

If Crosstab presentation style is used, then there is no need of four

reports. Instead, paint one and PowerBuilder will take care of the rest.
PowerBuilder also prints the summary at the end of each record (right
most side) and at the end of the report. Well, you can also print footer for
each page. Let's see how to paint this type of DataWindow.

To create the DataWindow, follow the same steps you followed for the
previous DataWindows, but select "Crosstab" presentation style. This
time, select "trans" and "product_master" table. Paint the data source as
shown in the following picture:

For the example purposes we hard coded the query under

the "values"column. This query brings all the receipts for the month of
August 1996 from "trans" table. Switch to design view by
clicking icon. PowerBuilder prompts you for the Crosstab definition.
There are three parts to a Crosstab: columns, rows and
values. "Columns"appears in the header band and repeats at the top of
each page. The columns specified in the "Rows" prompt would appear on
each record, at the left most side. You can drag columns from 'Source
Data' ListBox and drop on other ListBoxes. The "Rebuild columns at
runtime" is a very important attribute. If you select this option,
PowerBuilder generates new columns at runtime, if necessary. For
example, in 'trans" table, we have data just for four days. Painting the
DataWindow at this time would generate four columns. If the "Rebuild
columns at runtime" option is not selected and the same report is
executed when it has data for all the days in August 1996, you still get
data for those four days only. But, if you select this option, PowerBuilder
generates the new columns at run-time on the fly. Click on the OK button.
Preview the DataWindow by clicking the Preview button. You might
find the Grand totals at the bottom useless, since the sum of Hard disks
and Monitors doesn't make sense. You can remove those totals at the
bottom. However, the totals on the right hand side are good.

In PowerBuilder 7, you work with user events in the Event List and Script views.
Defining user events is similar to defining object-level functions.

Usage

When you add a new event, a Prototype window displays above the script in the
Script view. You can hide the Prototype window using the toggle button to the
right of the listboxes at the top of the Script view. There are two toggle buttons: the
button on the right hides or displays the Error window.

The fields in the Prototype window are in the same order as the event's signature:
access level, return type, and name, and then for each parameter, how it is passed,
its data type, and its name. You can choose to map the user event to a
PowerBuilder message ID by selecting an ID from the dropdown listbox at the
bottom of the Prototype window. If you map the event to an ID, you cannot change
the return type and arguments.
To do this Do this
Define a user event Select Insert>Event from the menu bar or, in the Script
view, select [New Event] from the second dropdown list, or
in the Event List view, select Add from the popup menu
Open an event for In the Event List view, double-click the event's name
editing
Delete a user event In the Event List view, select the user event's name, then
select Delete from the Edit or popup menu
Save a user event In the Prototype window, define the user event's name and
tab to the next field. The user event is added to the Event
List view and saved as part of the object when you save the
object
Add, insert, or delete Click the Prototype toggle button in the Script view to open
parameters in a user the Prototype window if it is hidden. In the Prototype
event window, select Add, Insert, or Delete Parameter from the
popup menu
Mark an event for In the Prototype window, check the External checkbox
use in a generated
component
External Data Source
When data retrieval is considered, databases, SQL and queries cross the mind. However, they
aren't the only ones for storing data; you can retrieve data from an external source such as a text
file.

The reason we use DataWindow even though we are not dealing with the database is its power. It
has a good sorting, filtering, printing, and whole lot of other good features, which work efficiently
with only few lines of code.

An External Source means that PowerBuilder doesn't know the source of the data. That means that
we need to define fields for the Data Window along with their data type. SQL statements can't be
defined for these types of DataWindows. When you try to create a DataWindow with external data
source, PowerBuilder prompts for the fields' definition as shown below:

This is like the database table definition, providing the column names, data types and lengths. To
populate an external DataWindow programmatically we use file functions or embedded SQL
statements in the PowerScript code.

We need an external DataWindow for the Product_Management_System, so create it and declare

the result set as shown in the above picture.

Click the OK button and save the DataWindow as d_error_information. We'll be using this
DataWindow to display error information if something goes wrong in our application. We could use
window controls such as StaticText, SingleLineEdit and MultiLineEdit instead of this DataWindow,
but if we do, we would have to call a whole string of print functions to print the error information.
By using a DataWindow we can print all the information with only a single print function.
 SignalError() and PopulateError() Functions in
PowerBuilder
How to Populate the Error Object and Trigger the SystemError
Event

Overview of Functionality:
PowerBuilder has always given the developer the functionality to test error-processing scripts during development and
to create their own execution time system level errors using the SignalError() function. This functionality has been
enhanced starting in PowerBuilder 6.0 and after in two ways:
1) The SignalError( ) function has been enhanced to automatically populate four of the six properties of the Error
object, and
2) The new PopulateError( ) function allows the Error object properties to be set without actually triggering the
SystemError event.

SignalError( ) Function Enhancements

SignalError( ) is used in one of two ways.

1) During testing of an application, it can be used to trigger the SystemError event and examine/test how the
SystemError script handles the error. The error handling can either be default PowerBuilder error messaging or user
scripted error handling.
2) SignalError( ) can also be used in a production application. If the user error is so severe that you do not want the
application to continue, you can set values in the Error object and call SignalError( ) to trigger the SystemError event.
You need to include script in the SystemError event to recognize and handle the error you've created. If there is no
script in the SystemError, for this scenario, SignalError() does nothing.

Enhancement Made:

In PowerBuilder 5.0, any of the six properties of the Error Object a developer wanted to trap had to be
assigned/populated manually through script. These properties are:

Property
Data Type Description
Integer - Indentifies the line in the script at which the error
Line occurred.
Number Integer - Identifies the PB error number or the user created error
number.
Object String - Contains the name of the object in which the error
occurred. If the error occurred in a window or menu,
Object will be the same as WindowMenu.
ObjectEvent String - Contains the event in which the error occurred
Text String - Contians the text of the error message
WindowMenu String - Contains the name of the window or menu in which the
error occurred.

A PB 5.0 script example to invoke SignalError( ) would look as follows:

Error.Number = 101
Error.Text = "The network went down"
Error.Windowmenu = "w_emp"
Error.Object = "cb_process"
Error.ObjectEvent = "clicked"
Error.Line = 48
SignalError( )

In PowerBuilder 6.0 and after, SignalError( ) now requires only two parameters/properties be passed by the
developer ,
Error.NUMBER
Error.TEXT

The following Error object properties are automatically populated for you:
Error.LINE
Error.OBJECT
Error.OBJECTEVENT
Error.WINDOWMENU

Syntax:

SignalError(errornum, errortext)

Argument Description
ErrorNum An integer value that will be used for the
Error.Number field in Error Object
ErrorText A string that will be used to fill the
Error.Text field in Error Object

Example:

The same example script in PowerBuilder 6.0 and after would look as follows:

SignalError(101, "The network went down")

Benefit of Using the Enhancement:

1) Ease of use, now the developer only needs to remember the Number and Text properties ,and reduces the amount
of script from 7 lines to 1 line.
2) If the script should change, the developer does not have to constantly go back and change the line number that the
error occurs on, or any other properties that could be effected by the changed script.

PopulateError() Function
The PopulateError( ) system function allows the Error Object properties to be set without actually causing the error to
happen. To actually trigger an error, use SignalError( ) without any parameters (otherwise, the parameters specified in
the SignalError( ) function will overwrite those specified in the PopulateError( ) function).

Benefit of Using the Function:

The Error object can be populated in one script and the error can be signaled with SignalError( ) in another script.
Syntax:

PopulateError(errornum, errortext)

Argument Description
errornum An integer value that will be used for the
Error.Number field in Error Object
errortext A string that will be used to fill the
Error.Text field in Error Object