In a previous blog post I examined how we could use the Git MSSCCI provider from PB Software in order to use GitHub as a source code provider for PowerBuilder.

In this blog post we're going to take that to the next step, in that we're going to create a build machine separate from our PowerBuilder development machine and then set it up to perform continuous integration.  The term "continuous integration" has a somewhat ambiguous definition, but generally it means that:

• developers check in changes frequently (at least daily) and
• that build are done on a regular basis (at least daily, but can be as frequently as after each check-in)

Ideally, automated testing routines would be run on each build to ensure that feedback on any functionality that was broken by the latest code changes are returned to the developers as soon as possible.  Automated testing is outside the scope of this particular article

One of the new features added in PowerBuilder 2017 is a license free stand alone compiler and we're going to use that for this article.   If you are using a older version of PowerBuilder you could use the same approach using the command line argument feature of the PowerBuilder IDE, but it would require installing the full PowerBuilder IDE (including a license) on the build machine.  Alternatively, regardless of which version of PowerBuilder you're using you could use PowerGen in scripted mode.

TITLE – Window Internals at runtime

“OK, what window are you in?”

“The Spanner Controller window.”

So here I’m shooting for the browser, w_spanner_controller? Nope, no w_spanner anything. W_controller_spanner? Nope, no w_controller anything.

“OK, what’s in the titlebar?” I ask, my frustration growing.

“Untitled, what does that mean?”

Have you ever worked on a system that had literally hundreds of windows with names that are not intuitive? I’ve seen names like w_a13_6.

There are times that at runtime we would love to get information about a window from the user. If only there were a way…

This solution requires a two prong approach. It requires that you have a base class window and a base class menu (see the NOTE at the bottom). Let’s start with the window.

The ClassDefinition object was introduced in PowerBuilder 6.0 a long time ago. It allows you to retrieve information for an object at runtime. Most of us didn't pay too much attention to this object and it only attracts our attention when we see it in the debugger.

Listing the Objects from a Library

In the first article we had some theory about the ClassDefinition object and we were able to show the libraries of a PB application in a treeview control. This month, we read the objects from the libraries and inspect their content.

When a user expands an entry in the treeview, we check if it was expanded once already. If so, we don’t take any action. We code this in the itemexpanding event of the treeview control, where we get the clicked treeviewitem by calling This.GetItem. If it wasn’t expanded, we check if the level of the treeviewitem is equal to two, which means we’re expanding a library name. We could create an NVO to include all the logic for the parsing, but for demonstration purposes, I want to keep the things simple. We define all the functions we need on the window itself, but use arguments to refer to the controls. This will allow you to move the logic to an NVO later quite easily.

Back in 2003, Sybase introduced CodeXchange, an online forum that allowed developers to share code samples and collaborate on open source projects.  Unfortunately, in 2009 Sybase decided to shut down that system.  The PowerBuilder code samples that had been uploaded tp CodeExchange did eventually show up again in a CodeXchange section of the PowerBuilder wiki on SAP's SCN.  Appeon also obtained permission from many of the authors to post those same PowerBuilder samples on the Code Samples section of the Appeon site.

However, the people who had collaborator projects on CodeXchange needed another option, because neither the SAP PowerBuilder wiki or the Appeon Code Samples site allowed for collaborative development.  Aware of the pending shutdown, I moved the PFC and PBNISMTP projects to Microsoft's CodePlex.

The ClassDefinition object was introduced in PowerBuilder 6.0 a long time ago. It allows you to retrieve information for an object at runtime. Most of us didn't pay too much attention to this object and it only attracts our attention when we see it in the debugger.

In this article I provide an overview of the ClassDefinition object and related objects and explain the most important properties of these objects. I also include a step-by-step guide on how to build a simple object browser. This browser has a limited functionality like the browser included in the PowerBuilder runtime environment and can't replace products like PBLPeeper by Terry Voth or PBBrowser by OOWidgets.

The ClassDefinition Object Hierarchy
The classdefinitionobject is a descendant of the pbtocppobject. It's the ancestor of all the other objects used to describe the PowerBuilder objects. Each object in PowerBuilder has one property named ClassDefinition that references the ClassDefinition of this object.

User Preference/Customization Service

Users nowadays expect applications to remember settings and customizations between sessions.  This saves time, frustration, and improves productivity.

Here is an easy to implement, user customization service you can add to your Powerbuilder applications which stores configuration information in a database.  This gives the added benefit of portability to the users as nothing is stored in ini files or the registry.  It is PFC based but, with minor modifications, could be un-coupled from that if desired.

The main object is the n_cst_dbinifile NVO.  The export of it can be found towards the end of the article

Note the export makes use of the PFC n_cst_inifile and n_base NVOs but this can be stripped out if desired.

The service allows for default values to be set up and used if the user does not have their own set up (or when you give them the option to undo all their changes).  The service also keeps itself updated by retrieving the datastore at an interval of your choosing.

As of PowerBuilder 11.5, DataWindow columns have been able to have background gradients. In that gradients can be data-driven by expressions, this tip will review how columns can emulate bar graphs.

For this example, I’ve created a DataWindow object that displays sales orders by sales rep and I’ve created a computed field that displays each rep’s quantity of orders as a percentage compared to the total count of orders for all sales reps.

To have the column’s background gradient behave as a bar in a bar graph, first institute the background gradient itself. Here I’ve chosen a horizontal gradient that will be blue in color.