PowerBuilder Jobs

What's the first piece of code that runs when a PowerBuilder application is started? Ask a PowerBuilder programmer this question and you always get one of two answers, either it's the code in the open event of the application object, or it's the code in the constructor event of any non-standard objects defined in the variable types tab of the application object properties dialog. Well, both of these answers are wrong. Sometimes, but not always, there is another piece of code that runs. This is a bug that has been fixed in PowerBuilder 5.0.4 and 6.0, even though it was not noticed by most developers.

In PowerBuilder versions 5.0 through 5.0.3, the first code run may be the code in the constructor events of any non-visual objects for which the autoinstantiate attribute is set to true. I found this out accidentally after adding an object manager to the PFC to track object behavior at runtime. When autoinstantiated objects have descendants, extra objects will be created and lie around in memory, but just when these objects are created is somewhat unpredictable. The extra objects are actually created most commonly not when the application is started, but when the object is first autoinstantiated. I discovered this, and other interesting facts about object behavior in PowerBuilder and the PFC, by adding an object manager to the set of available runtime services.

I spent five years in operating system development back in the late 70s and early 80s, and have always had a strong interest in understanding software that I am using. So when I started my first serious PFC project in the spring of 1997, I took some time to understand the heart of the beast.

As part of this attempt, I hooked in a modified version of an object manager that I had used heavily in PowerBuilder 4.0. This took just a few hours of cut and paste, and it was well worth the effort. The goal of the object manager is simply to assure that every non-visual object created in the application is registered with the object manager, so that at shutdown time the application can find and destroy any objects that the programmer has "forgotten" to destroy. It's an excellent way to determine whether or not the application has any memory leaks, and can be extended in many other useful ways.