There has been some talk lately about the impact of the new .NET PBL and EXE format on applications that dynamically integrate InfoMaker reports (or other external PBLs). The concern is that since PowerBuilder has gone .NET and InfoMaker remains Classic, platform differences will break the integration mechanism that ties these two products together. In this article I'll take a look at the issue, provide some background for the uninitiated and propose a mechanism to bridge the gap.

For those of you not familiar with InfoMaker, it's a reporting tool featuring the DataWindow Object Painter and runtime engine wrapped in a power-user friendly tool. InfoMaker is a popular in Sybase shops where there is an ad hoc or admin-user reporting requirement. It is also bundled as a report writer with many commercial systems. Product synergy allows InfoMaker-generated reports to become part of the core PB application while still under the control of their admin creator. This integration is possible for two reasons: one, InfoMaker report definitions are syntactically equivalent to DataWindows; and two, InfoMaker stores its report definitions in a PBL in the same format that PowerBuilder does. Most notably, InfoMaker PBLs are fully PowerBuilder Classic compatible. I'll begin by taking a look at the PBL structure and the runtime API for accessing it.

What's in a PBL?
A PBL is a development time repository file for PowerBuilder source code. In Classic it contains both source and object code stored in a binary format. A PBL file has an internal file system that includes a directory of the objects that are stored within it. The PowerBuilder platform sports a full API for working with the PBL-based file system. The library system is integrated with most Painters and the workspace (solution) view. In Classic, PBLs are only accessible from outside PowerBuilder via a C interface API known as ORCA (object repository control interface). ORCA ships with PB Enterprise and is used by tool builders to interact with the library system. In both .NET and Classic, PowerScript exposes a limited library API that allows developers to get runtime listings of objects in PBL, and export and import object source code as strings. Using this runtime library API, PowerBuilder applications are able to read and display InfoMaker reports at runtime.

In PowerBuilder 12.NET source code files are out in the sunshine and plainly visible at development time. The proprietary PBL file is now a PBL folder in which the source files are stored in text format as .SRx files. Figure 1 shows the contents of a sample PBL folder. Because of the difference in the storage formats between the platforms, .NET applications cannot read or access PBLs stored in Classic format. Looks like InfoMaker integration is broken!

Figure1: PBL folder structure

A New Integration Mechanism
I wondered, could I directly export a DataWindow from Classic and import it into .NET? If I could, would it display properly? If I could do that, then I could once again integrate InfoMaker reports with my PowerBuilder application.

Before beginning the test, it's important to note that the PBL's internal directory is also stored in human readable XML format as a PBLX file. Let's take a look inside the PBLX to see how DataWindows are stored. To simplify our task, I prepared a PBL with just DataWindow Objects. Figure 2 shows the directory area of the PBLX listing the DataWindow objects it contains.

Figure 2: DataWindow objects inside the PBLX

Notice that the DataWindow source files are members of an ItemGroup element and are listed as Include attribute values within Compile elements.

To begin my test, I copied a PBL folder containing only DataWindows into the runtime environment so it would be accessible to my runtime code. Figure 3 shows the folder debug\bin folder structure

Figure 3: PBL folder in the runtime environment

Next I exported some DataWindows from Classic directly into the .NET PBL folder. I then used a text editor to add a <Compile > element for each DataWindow within the ItemGroup. Figure 4 shows the DataWindows from the Classic Workspace view.

Figure 4: DataWindows in Classic IDE

I then used a text editor to add a <Compile > element for each one within the ItemGroup. Figure 5 shows the elements I added to the PBLX file.

Figure 5: PBLX after adding DataWindows

Next I coded a little .NET utility program to display a list of DataWindows in a PBL in a DropDownListBox and to load and display a user-selected DataWindow. I ran my utility, pointed it at the altered PBL, and loaded one of the exported DataWindows. As you can see from Figure 6, it rendered perfectly.

Figure 6: Exported DW in .NET

The next step was to write PowerScript code to enable PowerBuilder to do all the heavy lifting. Two PowerScript Library functions are needed. The first, LibraryDirectory, returns a list of all objects of a specific type. The second, LibraryExport, returns a string with the source code for a requested library object.

Here's a little code snippet that illustrates usage; for more details see the PowerBuilder help doc:

//returns tab delimited text suitable for import into a properly structured datawindow buffer
ls_dws = librarydirectory('dws.pbl', dirdatawindow!)
//once you have the directory in a data buffer, you can know what's available
string ls_dwsyn , ls_errors, ls_datawindow
ls_datawindow = ...
//returns the complete syntax of a datawindow as a string
ls_dwsyn = LibraryExport("dws.pbl", ls_datawindow, ExportDataWindow!)

These functions can be combined into a Classic PB utility along with some File functions to automate the export process. Rather than putting files directly into the PBL folder, I recommend dropping them into a temporary folder where they can be picked up by the next part of the process.

Here's what you do on the .NET side. There's another Library method called LibraryImport. This function takes a DataWindow syntax string and imports it into a library using an object name you provide. Here's an example:

LibraryImport("dws.pbl",  as_dataobject,  ImportDataWindow!, as_syntax, ls_Errors)

You can wrap this call in a .NET utility surrounded by some file functions that allow you to select the file. This will successfully import Classic DataWindow syntax into your .NET dynamic reporting library.

Summary
Some code refactoring will be necessary when you migrate an application that integrates with InfoMaker. A Classic utility exports InfoMaker report syntax to some intermediate location. A .NET picks up syntax and imports it into the runtime PBL.PS. I have done this with version 3 and 4 DataWindows, as well as version 12 Classic DataWindows. Directly in, with no intermediate migration necessary.

Limitations
There are a couple of exclusions you need to know about before going gleefully down the trail. First, LibraryDirectory will not report on Composite DataWindows and those DataWindows whose sole purpose is to be dropdown children inside other DataWindows. Second, if DataWindows you import reference child DataWindows that are not in your executable, the dropdowns will be missing at runtime.