It's been the bane of PowerBuilder development since day one. You have a DataWindow that contains one or more text blocks that, when previewed for printing or printed, span a page boundary. The result: the DataWindow incorrectly handles portions of the text. You may find some text on the first page that is repeated on the next page, or some text may be missing entirely, or the text may end up overwriting subsequent report objects. The bottom line is that the results are unusable, and it often takes a great deal of tweaking to get adequate results. The good news is that I found at least one method of addressing the issue. The bad news is that the path to get there was rather convoluted. This article describes both.

Beginning with PowerBuilder 9, the DataWindow has had the capability of exporting into XSLFO (XSL formatting objects) format. XSLFO is a variation of XML that contains formatting information in addition to the data. It is intended for use by a FOP (formatting objects processor) to render into any number of final output formats (e.g., PDF, RTF, HTML, etc.). In some sense it's similar to HTML, in that it contains formatting information and also because the syntax is somewhat similar. If you want to learn more about the actual structure and syntax of XSLFO documents, I recommend the tutorial on the w3schools site: http://w3schools.sinsixx.com/xslfo/default.asp.htm. Referring to that may be helpful when I start discussing some of the current limitations of PowerBuilder's XSLFO implementation. There is another good tutorial at the RenderX site: www.renderx.com/tutorial.html. If you want to work directly with XSLFO documents and render them to PDF manually to see the result, I'd recommend the editX editor: www.editix.com/

Microsoft recently released the Interop Forms Toolkit 2.0 in order to allow "developers to incorporate VB.NET Forms and Controls into their VB6 applications" (www.microsoft.com/downloads/details.aspx? FamilyID=934de3c5-dc85-4065-9327-96801e57b81d&DisplayLang=en).

The interesting thing is that it operates by automatically generating a COM Callable Wrapper (CCW) for the VB.NET forms and controls. That means that the .NET visual user controls are not only available to VB6, but to any Win32 application that supports COM, including PowerBuilder.

To test it out, I wrote a simple gradient user object in VB.NET (see Listing 1) and deployed it as an interop user control. I then added it to a PowerBuilder 10.5 window as an ActiveX (see Figure 1).

Everything on the window, with the exception of the gradient control, is standard PowerBuilder stuff. After some simple calculations to determine the combined RGB value the user has selected through the sliders and display it, it is applied to the gradient control through the following (of_calcstart and of_calcend are the routines used to calculate the RGB values):

long ll_start, ll_end
ll_start = of_calcstart()
ll_end = of_calcend()

//This will actually cause two repaints, but I don't care
ole_1.object.StartColor = ll_start
ole_1.object.EndColor = ll_end

It will come as a surprise to no one that PowerBuilder's native graphing capabilities are somewhat lacking. Even the Define Graph Style dialog for the DataWindow graph style seems to have been left out of the GUI update in PowerBuilder 10.5 (see Figure 1). Forget Windows 95, this looks like something out of the version of Excel that came with Windows 3.1.

So what would we want from updated graphing capabilities? I can think of a few important features:

1. Something that would work equally well in a Web application as a client/server one.
2. Transitions, to allow some animation in the graphic during its initial display.
3. Click-through, making it possible to respond to actions on the chart to drill down into additional information, whether it be additional charts or just access to the underlying data.
4. More control over the generation of the chart. For example, for 3D pie charts we should be able to explode segments and have control over the amount each segment is exploded.
5. An updated look-and-feel. That's a little hard to put into words, but what we want to do is make Figure 2 look like Figure 3.

Back in August of 2006, I wrote an article about calling .NET components from PowerBuilder using COM wrappers (i.e., CCW). Since I was basing it on a registry entry approach, the technique demonstrated required the component to be added to the GAC, which in turn required that we create a strong name and sign the assembly (besides having it compiled as a COM-visible assembly).

You don't always have access to the GAC or the registry of the machine that you need to deploy your application to. Well, fortunately we have some options. Beginning with Windows XP and Windows Server 2003, the Microsoft operating systems allowed the use of manifest files rather than registry entries for loading COM components. It not only works for regular COM components, but for .NET components that have been exposed as COM-visible. The only difference is how the manifest file is structured.

If you want further information on the details, I'd recommend the following resources:

This two-part article provides a primer on OLE, some practical examples of its use, and demonstrates some methods for addressing the limitations of PowerBuilder's implementation of OLE.

In Part 1 I provided some background information for OLE and discussed the use of custom controls, in Part 2 I talk about OLE Automation and OLE objects.

OLE Automation
OLE Automation is the interface through which one application (e.g., Microsoft Outlook) makes the methods, properties, and events of its objects (e.g., Folders, Messages, Address Book) available for use within another application. Using OLE Automation, a developer could automate another application (e.g., creating and then printing form letters from Microsoft Word) or they may just use a portion of another application within their own (e.g., using the spell-check capability within Microsoft Word to spell-check text in a control within PowerBuilder).

Using Object Linking and Embedding (OLE) from PowerBuilder - whether in OLE Automation or the use of ActiveX controls - has long been a source of frustration for many PowerBuilder developers.

There are several reasons for this:

• There is a lack of a full understanding of OLE.
• There is little documentation and practical examples of using OLE with PowerBuilder.
• There are some limitations inherent in the method that PowerBuilder implements OLE.

This article is intended to address some of these issues by providing a primer on OLE, providing some practical examples of its use, and demonstrating some methods for addressing the limitations of PowerBuilder's implementation of OLE.

The first thing we need to do is cover some background information, beginning with some definitions of terms and then some explanation of how OLE works.