The art of solving performance problems

Enterprise Application Performance

Subscribe to Enterprise Application Performance: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Enterprise Application Performance: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Application Performance Authors: Elizabeth White, Jason Bloomberg, APM Blog, AppDynamics Blog, John Worthington

Related Topics: Enterprise Architecture, Enterprise Application Performance


Using Third-Party WPF Controls with PowerBuilder .NET 12.0 WPF Targets

State-of-the-art graphical user interfaces are once again possible

One of the things that PowerBuilder developers have been asking for years is the ability to include state-of-the-art graphic elements in their applications. With the advent of WPF Targets in PowerBuilder.NET 12.0, that capability has finally arrived.

You can do quite a bit with the new layout managers, the skinning capabilities, effects, etc., directly within the IDE. For example, look at the following few lines of XAML code. The highlighted code is what I added; the rest was generated automatically by PowerBuilder.NET when I placed the commandbutton on the WPF window.

<pbwpf:CommandButton Height="28" HorizontalAlignment="Left" Margin="164,176,0,0" Name="cb_1" TabOrder="20" Text="none" TextSize="-10" VerticalAlignment="Top" Width="88" PBHeight="112" PBWidth="402" X="750" Y="704" FlatStyle="False" AllowDrop="False">
<BlurBitmapEffect Radius="10" KernelType="Box"/>

The result is a PowerBuilder commandbutton with a blurred presentation (see Figure 1).

Figure 1

I imagine however that where the move to WPF will have the most effect for most PowerBuilder developers is when they use third-party WPF controls to implement certain graphic capabilities without having to do a lot of coding of their own. In this article, we're going to look at how simple that is to do with PowerBuilder.NET.

The particular third-party control I'm using for this example is the Actipro Ribbon ( ), which allows you to add an Office 2007 like ribbon control to the windows in your WPF application. When you install the product, it would normally register the controls (both the ribbon itself and the child controls they provide to place on it) in the toolbox in the Visual Studio IDE. Since PowerBuilder.NET runs in the Isolated Shell version of the Visual Studio IDE, the controls don't get added to the toolbox automatically. That's no problem though, as it's simple to add them ourselves.

First, go to the PowerBuilder.NET Toolbox, right-click on it and select "Add Tab." I renamed the new tab as "Ribbon Control". Now right-click in that new tab and select the "Choose Items..." option. That will eventually bring up the Choose Toolbox Items dialog (see Figure 2). I say eventually because that dialog is typically slow to open (in Visual Studio as well). When it does finish opening, it will be showing the ".NET Framework Components" tab by default. We need to click on the "WPF Components" tab, which will also take some time before it displays. Once that does display, you can select all of the controls provided in the Actipro assembly and hit OK.

Once the controls are added to the tab in the Toolbox, you may want to arrange them in some order that makes sense to you. You can drag and drop the controls within the toolbox tab to reorder them. I like to have them sorted alphabetically, and there is a right-click mouse button menu option "Sort Items Alphabetically" that makes that real simple. You should end up with something like Figure 3.

At this point, you can drag the Ribbon control onto your WPF window. Once you've done that, you have a few options with regard to how you can add child controls to the ribbon. One thing I didn't find particularly effective was dragging the controls from the toolbox onto the ribbon. That didn't seem to get the control to recognize the ribbon as its container. I also found that dragging and dropping the control from the toolbar into the XAML did allow me to place it within the ribbon container, but the "ribbon" prefix wasn't included when the control name was included in the XAML.

Instead, the first two options for adding child controls are provided by the ribbon control. If you right-click on the ribbon control, or on controls within the ribbon control, you get a context-sensitive menu that allows you to add child controls (see Figure 4). Or you can also click on the small right arrow button on the top of the selected control and pull up a context-sensitive Task dialog (see Figure 5).

However, after a short time I got comfortable working with the control and found that the easiest method of all was simply to edit the XAML directly. That may seem counterintuitive at first, particularly to long-time PowerBuilder people who are used to "painting" a window. However, particularly because the Intellisense is right there all the time prompting you with possible choices, it's actually quite simple once you get comfortable with it. It's particularly important when you have a lot of nesting of controls, such as you do with a ribbon control. Fortunately, since the Design and XAML panes are both available simultaneously, you can always "paint" in the Design pane and then move to the XAML pane for fine tuning when needed.

Once you've got all the controls laid out, you'll want to assign image resources to the buttons. If you didn't create a "Resources" folder when you first created the target, you can add one now, then copy all of the images you're going to use into that folder. PowerBuilder.NET will automatically recognize that the images in that folder should be compiled into the assembly it generates (no more PBR files!). In the button properties, or in the XAML itself, I simply referred to the images files using a relative reference to the Resources folder:

<ribbon:Button ImageSourceSmall="/Resources/Bold.png" Name="boldbutton"/>

For the most part, I'm using 16x16 alpha blended PNG files. Some are from the glyFX free set ( and the rest are from the Glyfz Office 2007 Ribbon Bar Icons, Word Processing Set 1 (, which I did have to buy but it cost less than $40. The end result should look something like Figure 6 (note that I don't have images for all the buttons yet).

That's all well and good, but at some point we want to put some code behind those fancy graphics. Here's where it gets real interesting. When you code WPF in Visual Studio, you need to implement some form of Event Routing to respond to actions on the controls (see Routing Events Overview: As you would expect from a 4GL, PowerBuilder.NET makes it a lot easier. Simply name the controls that you want to code events on (making sure that the name is entirely in lower case). XAML doesn't require you to name controls, but once you do give the control an all lowercase name, PowerBuilder.NET will recognize that you want to code events on it. At that point, go to the Script painter for the window, and you'll find that the first dropdown with the list of controls in the window suddenly has the control you just named in it. Select that control, and you'll find that the second dropdown lists all of the events that the control can generate. Simply find the event you want to respond to and add your code (see Figure 7). For this demonstration, I'm adding code to the PreviewMouseLeftButtonDown event that gets fired when the user clicks on one of the buttons in my ribbon control, specifically the bold button (named boldbutton).

That's all there is to it. State-of-the-art graphical user interfaces are once again possible with PowerBuilder. The only limitation now is your imagination.

More Stories By Bruce Armstrong

Bruce Armstrong is a development lead with Integrated Data Services ( A charter member of TeamSybase, he has been using PowerBuilder since version 1.0.B. He was a contributing author to SYS-CON's PowerBuilder 4.0 Secrets of the Masters and the editor of SAMs' PowerBuilder 9: Advanced Client/Server Development.

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.