Related Topics: Apache Web Server Journal

Apache Web Server: Article


Create applications that use the full power of the DataWindow

Command-Line Arguments
One of the new features added in version 8 of InfoMaker allows the end user to respond to command-line arguments passed to an application created with InfoMaker. Reports, forms, and pipelines can be passed as arguments (see Table 2). The arguments are passed in the form:

exename /switch <object_name> /a <arg1;arg2;...<argn>>

For example, to call the customer_list report within an application called myreports and using Canada as a retrieval argument, you would use:

myreports.exe /r customer_list /a Canada

New File Save Formats
Three new formats have been added:

  • PDF: You're no longer dependent on third-party tools to generate PDF files. All report styles, including composite, nested, and graph, are supported.
  • XSL-FO: XSL-FO is a language for completely describing a styled document, including its content organization, styling, layouts, and layout-selection rules - everything necessary to format and paginate it. The document is then fed into a formatter, like Apache FOP, which can then generate PDF, PCL, and a PS output file.
  • XML: The big new feature added in version 9 was support for XML. By defining Export Templates, end users can create their own layout when saving reports. The templates allow you to add elements, DataWindow expressions, processing instructions, etc. For instance, computed fields can now be saved. Figure 2 shows a basic example, where the new_salary computed field has been added to the XML template.
End users can create as many templates as desired for each report. When they save a report using "File, Save Rows As, XML," the XML file will be created using the default template. If they have specified a template using the new "Data Export" tab on the report properties panel, that template becomes the default and is used for subsequent exports.

Where Does PowerBuilder Fit In?
Since InfoMaker is a subset of PowerBuilder, it's immediately clear that you can share objects and libraries between the two. For example, to use InfoMaker reports in a PowerBuilder application, you can use the following approaches:

  • Add the pbl to your own application and compile it as a PBD.
  • Import the reports into your application using the LibraryImport() function.
  • Add the executable created with InfoMaker to your application using SetLibraryList(). In the application open script you would code:

ls_list = GetLibraryList()
SetLibraryList(ls_list + ",imreports.exe")

However, it's also possible to use PowerBuilder objects within InfoMaker, though the implementation is trickier. One reason is that InfoMaker does not have an Import function in the Library painter. In the following sections we will explore how we can use PowerBuilder to create custom form styles, modify existing forms, and create actions. Finally, we will get into the heart of InfoMaker by customizing the imstyle9.pbl.

Custom Form Styles
A custom form style is nothing more than a window and its associated menu that have been created in PowerBuilder and made available for use in InfoMaker. The window must be saved with a comment that starts with the word "Style:". This indicates to InfoMaker that the window is to be used as a custom form style.

Although the custom form style can be saved in the imstyle9.pbl, it's better to create a new pbl (for example, imforms.pbl). The InfoMaker end user then adds this pbl to the library search path using the "Library List, Style Path" menu in the Library painter. When end users create a new form, they will now have additional form templates to choose from, as shown in Figure 3.

Default Form Styles
The default form styles use a specific naming convention for the DataWindow controls (see Table 3). Based upon these names, InfoMaker automatically invokes the SQL painter when the user creates a new form.

When the end user creates a new freeform in InfoMaker, InfoMaker automatically generates a DataWindow that has the name of the form appended with @1. For example, form myfreeform has a DataWindow myfreeform@1. The other three form styles (grid, one-to-many, and many-to-one) each have two DataWindows associated with them, one a freeform style and one a gridstyle. For example, mymasterdetailform has DataWindows mymasterdetailform@1 and mymasterdetailform@2. (Note: The "@2" DataWindow on a gridstyle form is the visible DataWindow. The "@1" is used for sharing data.) Every DataWindow is automatically set to be updateable. But you cannot set the taborder for the gridstyle DataWindows. In the section "Toolbar Settings in the Registry" a workaround will be shown that allows the end user to set the taborder for gridstyle DataWindows on forms.

Even though these DataWindows are not displayed in the InfoMaker Library painter (in PowerBuilder you can see them in the Library painter), they can be modified in the InfoMaker Report painter: you just need to type the name in when selecting a report for editing. This gives users some additional flexibility in changing the layout of the DataWindow if they don't have access to PowerBuilder.

The easiest way to start building custom forms is by inheriting from the built-in form styles in imstyle9.pbl:

  • Freeform: w_pbstyle_freeform
  • Gridstyle: w_pbstyle_grid
  • Master/detail one-to-many: w_pbstyle_mst_det_12many
  • Master/detail many-to-one: w_pbstyle_mst_det_many21
For menus you can inherit from m_pbstyle_sheet_ancestor.

When inheriting from the built-in form styles, be aware of the standard resizing methodology. These form styles all have a freeform DataWindow (dw_freeform for freeform and gridstyle, dw_master_12many for one-to-many style, and dw_detail_many21 for many-to-one style). This freeform DataWindow is automatically resized to the size of its parent window in InfoMaker. For example, setting the background color on the window is not going to work, because the window background will never be seen.

Even though it may sound obvious, once an InfoMaker user has developed a form based on a custom form style, it's almost impossible to modify the form style without breaking the InfoMaker form that is based on it. In most cases you'll need to drop the form and rebuild it from scratch in InfoMaker.

When InfoMaker end users place a command button on their form, they assign an action to the command button. The built-in forms come with a set of predefined actions for doing basic things like retrieving, sorting, and filtering. None of the built-in actions require any parameters.

To add a new action, first define a public window function. Arguments can be passed to the function if required. Listing 1 shows an example of a function called ShowHelp that requires the name of the helpfile as an argument (see Figure 4).

The InfoMaker user will see an action called ShowHelp that requires the parameter Helpfile.

Toolbar Settings in the Registry
As noted earlier, the Report painter does not have the Tab Order icon, since reports are supposed to be read-only. But what if you want to change the tab order for certain columns on a form that has a gridstyle DataWindow?

To accomplish this in InfoMaker, we need to change a registry key. Please note that modifying the registry is dangerous. Done without care, it can render your system useless. Be aware that Sybase does not support modifying toolbars by changing the registry directly. This method also might not work in future versions.

The settings for the toolbars are stored under the key [Hkey_current_user\Software\Sybase\InfoMaker\9.0\Toolbar]. The report settings are under the subkey(s) 1007 X (X being 0, 1, 2, or 8. These correspond to the different painterbars in the Report painter). If you have never customized any of the toolbars, these subkeys will not exist. The moment you customize a toolbar, either by adding or deleting an icon, the subkey gets created. Each subkey has an Items value that looks like this (your settings might look different, depending on the icons you have selected):

Items = "1452 1438 -1 1258 1348 -1 724 -1 1260 1262 1264 1266 -1
2136 2130 -1 1738 1274 2290

More Stories By Terry Dykstra

Terry Dykstra is a database administrator/developer for Canadian Forest Oil Ltd in Calgary, AB. He has used InfoMaker/PowerBuilder since version 3 and has been a TeamSybase member since 1996.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.