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.

Here is a technique you can use to resize a response window or userobject as needed. It makes use of the GetWindowLong and SetWindowLong Windows API methods. The oldest reference I found to this is from Eric Aling back in 2000.

In a nutshell, you are changing the border around the object to one which Windows allows to be resized. What's even nicer about this is the standard resize events are triggered so you can reposition/change objects within the window as well (PFC resize service for example). From Eric's original post:

"The Get function retrieves the complete definition of the window in 
a big long variable. All the bits in this long value describe the window. 
So there are bits for the type of border (which indicates if a window is 
resizable), menu, colors etc.etc. We can modify this long value, altering 
the design of the window. Using the SetWindowLong() we update the window with 
our specific modifications."

I used this in ancestor code of a userobject I use to create visible panels within the main window.

Here is an easy to implement service geared towards developers who are working on complex, many layered applications. In its basic form it shows the current window object, which pbl it is located in, all the various ancestors of the window, their pbl locations, all datawindows and datawindow objects on the window, and the sql statements for those datawindow objects.

The only dependency in the window is the pfc resize service. This can easily be stripped out if needed.

To implement the service, add the following to the window/ancestor window event (rbuttondown for example):

openwithparm(w_window_info,THIS)

The screenshot is an example output.