User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

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).

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

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.

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

Thank you Sandy Barletta!

Just after the earth began to cool (I think it was in the PB3 time frame), I discovered the DWSyntax tool created by Sandy.

‘Round about that time I had been exporting DataWindow objects (this was before “edit source” folks) in order to get functional syntax for my dwModify() calls. Lo’ and behold I discovered this nifty GUI that would allow me to browse the dwDescribe(), dwModify(), SyntaxFromSQL() argument syntax for any DataWindow item or for the DataWindow object itself.

Fast forward to the present day. Let’s say you need to change the expression of a computed field at runtime, much as I illustrated in another tip on dynamically “creating” DataWindow groups.

From the PowerBuilder IDE, open the “New” dialogue. Select the “Tool” tabpage, and then select the “DataWindow Syntax” item.

Image

 

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

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.

User Rating: 2 / 5

Star ActiveStar ActiveStar InactiveStar InactiveStar Inactive

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 Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

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.