Related Topics: Apache Web Server Journal

Apache Web Server: Article


Create applications that use the full power of the DataWindow

Each item corresponds to a toolbar icon, e.g., 2290 is Close Painter; -1 is the separator. The number 1468 represents the Tab Order icon. Simply add this value to the Items value so that it looks like:

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

You can now set the tab order on InfoMaker reports. Setting the tab order does not make a report updateable. It only has a function when modifying the gridstyle DataWindows that InfoMaker has generated when building gridstyle forms.

Non-Default Form Styles
There's no reason to strictly follow the conventional method of building custom forms. When you don't use the standard DataWindow control naming convention, InfoMaker won't automatically invoke the Query painter to build the DataWindow(s). Instead the user assigns his or her own reports to the DataWindow control. This gives the end user more control.

To demonstrate how easy it is to build a form style using this method, simply create a window w_custom with one DataWindow control dw_nocoding. Save the window with the comment "Style:Quick demo". Now in InfoMaker build a form using "Quick demo". Assign a report to the form, save it as "form_nocode", and run it. It retrieves! Not one line of code was required!

InfoMaker has done the basic coding for you. If you look at the open event for "form_nocode", you will see:

Call super::open;
dw_nocoding.SetTransObject( SQLCA )

Obviously this is a simplistic example. Apart from not having to code the SetTransObject (SQLCA) and Retrieve () in the open event of the form, all the regular rules and restrictions of default form styles apply to the nondefault form styles.

Customizing the imstyle9.pbl
Starting with InfoMaker release 6, it has been possible to modify the imstyleX.pbl directly using PowerBuilder (X corresponds to the InfoMaker release). The imstyle9.pbl is essentially a class library for InfoMaker. It contains all the objects from which InfoMaker inherits. Change the library and you change the behavior of InfoMaker applications.

Most changes to the imstyle9.pbl do not affect the InfoMaker development environment, since there is no application that you can run from within the tool. Changes are reflected in the generated executables. However, when modifying objects related to forms (for example, adding an action to the w_pbstyle_grid window), end users immediately see that change when they build and run a new form in InfoMaker.

The main reasons for modifying the imstyle9.pbl are:

  • Enhancing existing form styles.
  • Adding functionality to executables, like e-mail integration or simpler filter capabilities.
  • Bug fixes; for example, in the w_pbstyle_report open event a dw_report.Groupcalc() is required to ensure that complex reports calculate computed fields correctly.
Before modifying imstyle9.pbl, it's highly recommended that you make a backup of the original. Once you've made changes, you can use a tool like PBDelta ( to quickly determine the differences between your custom pbl and the backup of the original.

To edit the imstyle9.pbl in PowerBuilder, you first have to create a dummy application object because it does not contain an application object.

While you can build almost any type of form or customize the imstyle9.pbl, there are some limitations in InfoMaker you need to be aware of:

  • Everything gets compiled into one executable. You cannot create PBDs or use a PBR file to force objects into the executable. This means that dynamic assignments will fail:

    Dw_1.DataObject = "d_employee"

    In the development environment this will work, but not in an executable. Even though you can't create PBDs, it's still possible to add existing PBDs to the library path using SetLibraryList. This should be done in (open event of) w_pbstyle_frame_ancestor.

    ls_list = GetLibraryList()
    SetLibraryList(ls_list + ",custom.pbd")

  • You cannot use global variables since the default application object gets regenerated with every compile.
  • You cannot use global external function declarations for the same reason.
  • Modifications made directly to objects in imstyle9.pbl are lost when upgrading to a newer version of InfoMaker. You will need to re-create the modifications with each upgrade.
Debugging Your Code
Debugging your custom forms or imstyle9 enhancements is not as straightforward as you might expect. The problem lies in the application open script. When you create an executable in InfoMaker, the script in Listing 2 is automatically generated.

The window w_pbstyle_frame that's used in the OpenWithParm() call does not exist in either imstyle9.pbl or the InfoMaker work pbl. InfoMaker generates w_pbstyle_frame and its associated menu m_pbstyle_frame when it creates an executable. To run your code through the debugger, you need to add the generated executable to the Library Search Path. Be sure to recompile the executable in InfoMaker before starting a debug session to prevent crashing your system.

An interesting thing to note is that you can see the actual code for objects that were created by InfoMaker during compilation. For example, you can see the code in menu m_pbstyle_frame, but you cannot see the code in its parent m_pbstyle_frame_ancestor.

Writing Code in InfoMaker Forms Without PowerBuilder
Even though InfoMaker officially does not support writing PowerScript, it's actually possible to write code in forms developed in InfoMaker without requiring PowerBuilder. The registry tweaks required to accomplish this are most definitely not supported by Sybase.

To enable scripting in the Form painter, it is necessary to create a registry entry that creates a new layout:

"mycode"="PBTR{0 PBTB{1 PBPL{0 0}WSCL{0 }WSNC{0 }WSL{0 }WSS{0
40%40%20 39 33 0 1 1}WSFL{0 }WSEL{0 }4 }100 }"

Creating this registry adds a new layout in the Form painter called "mycode" that can be accessed through menu option "View, Layouts, mycode". When this layout is selected, you get full access to the properties, control list, nonvisual object list, layout, function, and event panels.

To make it easier to write your scripts, create an additional painter bar that gives you the default buttons for pasting function templates, statement, variables, searching, and compiling your script:

[HKEY_CURRENT_USER\Software\Sybase\InfoMaker\9.0\Toolbar\1010 1]
"Items"="1268 -1 1270 1272 -1 1324 1326 1328 -1 1334 -1 1330 1332
1276 1352 1354 1356 1358 1360 1362"

Unfortunately, we cannot insert any "PowerBuilder" objects, like NVO or PictureHyperLink controls. To be able to do that, we need an additional entry that adds the icon containing the PowerBuilder controls:

[HKEY_CURRENT_USER\Software\Sybase\InfoMaker\9.0\Toolbar\1010 0]
"Items"="2318 -1 1260 1262 1264 1266 -1 1258 1348 -1 736 -1
1456 -1 1468 1274 1428 -1 2290 726"

Number 726 in the Items list refers to the PowerBuilder Controls icon. Number 736 refers to the InfoMaker Controls icon, which contains a subset of the PowerBuilder controls. If desired you can remove the 736 entry.

Using these three registry entries, you now have full scripting capability in the InfoMaker Form painter, albeit with some limitations. Adding code to a command button is a little awkward. When you right-click on the button, you can't go to "Scripting"; there's only the default "Action." Select "Properties," then the "Event List" pane where you can code the clicked event.

It's also possible to add the DWSyntax utility to your menus. DWSyntax gives the proper syntax for accessing DataWindow objects. Right-click on the Powerbar, select Custom, and drag an icon from the "Selected palette" into the "Current toolbar." Use the following settings:

Commandline: wizard:?action=runonly&entry=k60_dwsyntax_sheet
Itemtext: dwsyntax
Item Microhelp: Datawindow Syntax

Be aware of one major drawback: when you try to build a new form and you're not in the Default Layout mode, the form creation will fail. You must use Default Layout to build the initial form. Once the form has been created, you can switch to Mycode Layout.

InfoMaker is much more than just a great reporting tool. It allows end users to create powerful applications that use the full power of the DataWindow for reporting. Reports can use global functions developed in PowerBuilder. In addition to reports, pipelines for transferring data between databases and forms for updating data can also be included. End users do not have to write one line of code to create these applications.

The default data entry forms in InfoMaker are fairly basic. Using PowerBuilder, custom form styles can be developed for use in InfoMaker. There are two types of form styles: default and nondefault. Default form styles automatically generate DataWindows; nondefault form styles require end users to build their own DataWindows.

By modifying the imstyle9.pbl, InfoMaker's capabilities can be further extended.

Because InfoMaker and PowerBuilder share the same code base, it's very easy for end users and developers to share objects and libraries.

This article is based on PowerBuilder 9: Advanced Client/Server Development by various authors (ISBN 0672325004), published by Sams Publishing. Also look for PowerBuilder 9 Internet and Distributed Application Development.

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.