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: Alex Forbes, Elizabeth White, Jyoti Bansal, John Worthington, JP Morgenthal

Related Topics: Enterprise Architecture, Enterprise Application Performance


A Snap-In App Framework Using Dynamic PowerBuilder Assemblies (Part 2)

Part 2: A PowerBuilder .NET use case implementation

This two-part series examines and contrasts PowerBuilder .NET 12.5.1's new dynamic assembly feature with corresponding dynamic library functionality in PowerBuilder Classic. The discourse is presented in the context of a simplified yet practical use case. Part 1 presented the use case, reviewed pertinent PowerBuilder Classic dynamic APIs and presented a Classic PBD implementation. Part 2 introduces PowerBuilder .NET 12.5.1's Dynamic Assembly feature, reveals relevant PowerBuilder .NET generated assembly internals, and presents a PowerBuilder .NET use case implementation. Along the way it explores PowerBuilder assembly internals.

My initial attack plan when exploring version 12.5.1's dynamic assembly function capabilities was to envision a use case where library functions are used to reflect on an assembly to discover its contents and then extract and instantiate class definitions. I am so used to writing dynamic Classic PowerScript code using Library functions to get lists of objects in a PBD and dynamically creating them that I naively assumed that the .NET Library methods were equivalent to their Classic counterparts. Wrong! As you'll soon see, my journey took me spelunking deep into the cavities of PowerBuilder .NET assemblies. Lucky for me I got the treasure at the bottom of the cave and was able find my way back out. Read on!

PowerScript Dynamic Assembly API
In the .NET world, a PBLX is the file-based equivalent of a PBL that you access under the control of the PowerBuilder library API. Just like the PBL, a PBLX has a library directory with managed access to the directory's contents. Pertinent to our discussion, the functions CreateLibrary, DeleteLibrary, LibraryDirectory, LibraryDirectoryEx, LibraryImport and LibraryExport all work as advertised in their Classic form when called in .NET. The sole difference is that they operate on a PBLX or its contents.

Remember that in Classic, a PBD is basically a PBL sans source code. In addition to their important role as runtime libraries, you can add PBDs to an application library list, and create or inherit from their code objects as if they were inside PBLs. The nice thing about runtime libraries in Classic is that with proper forethought you can turn any library on your library list into a standalone PBD that you can use within any application.

Things are a bit different in the .NET world where the PBD has gone the way of the wooly mammoth. There is no such thing as PBD generation nor are PBDs reference-able on a .NET application. The replacement technology is the PowerBuilder .NET Assembly.

To generate a standalone PB .NET Assembly use the IDE to create a PB Assembly Target to which you add the libraries containing code objects you want in your Assembly. Use the Project painter to generate the target's contents as a freestanding DLL. However, since the libraries are generated as DLLs you cannot add them to your library list. You must add them as referenced assemblies on your PowerBuilder application. Once reference-able, you can create or inherit from their code objects just as if they were inside your PBLs.

As mentioned, a PBLX is the file-based equivalent of a PBL; both are accessed by the IDE under the control of the PowerBuilder library API. However, since a PowerBuilder .NET Assembly has no structural relationship to a PBD, the Classic PBL/PBD-centric library functions AddToLibraryList, SetLibraryList and GetLibrary are obsolete in .NET. Sadly for those migrating a Classic application containing these functions, there are no migration or PBCS compiler warning messages; the functions just do nothing at runtime. Worse yet was that there was no functional replacement in the PowerBuilder .NET world; that is until the release of version 12.5.1. This version brings relief to those whose applications rely on adding classes at runtime. Three PowerBuilder Assembly oriented replacement functions were added: AddAssemblyReference, SetAssemblyReference and GetAssemblyReference. These functions are operationally equivalent to their Classic counterparts with the exception that they operate on PowerBuilder assemblies instead of PowerBuilder dynamic libraries. Once a PowerBuilder Assembly is added to the assembly reference list, its contents are fully available to the runtime. Any global function, PowerObject type class or DataWindow object can be created or referenced in code. Of course, since the code objects are not present at build time, you will need to create them using one of the dynamic open or Create methods I illustrated in the first article in this series.

The Missing Link
Table 1 shows differences and similarities between Classic and Dot Net Library Functions.

Table 1: Library function comparison chart

Classic Function

Classic Purpose

.NET Function & Variations


Adds files to the library search path of the application

AddAssemblyReference( )


Gets the files in the library search path of the application

GetAssemblyReference( )


Create a library and add comments to it

Creates a PBL folder*


Delete a library

Deletes the PBL folder *


Returns a list containing all the objects of a specified type in BOTH PBL & PBD

Only works for PBLX

Doesn't work on Assy!!



Returns a list containing all the objects in a library in BOTH PBL & PBD

Only works for PBLX

Doesn't work on Assy!!


Exports an object -from- a specified PBL to a string

Works for PBLX


Imports an object -into- a specified PBL from a string

Works for PBLX


Changes the files in the library search path of the application

SetAssemblyReference( )

Note that there is just one omission: LibraryDirectory and LibraryDirectoryEx are not implemented to return the contents of a referenced PowerBuilder assembly. Similar to AddToLibraryList a call to LibraryDirectoryEx does not generate a compiler warning and does not return a runtime response. Unfortunately for us, runtime Assembly directory functionality is a crucial aspect of our snap-in loader architecture. What to do?

Into the Cave: PowerBuilder Assembly Internals
At this point, I realized that I would have to write my own PowerBuilder Assembly directory functionality. Lucky for us PowerBuilder .NET is a CLR compliant language; I had a full arsenal of .NET 4.0 Framework classes and the strength of the great .NET disassembly tool, Red Gate Software's .NET Reflector. What I needed to do was generate a PowerBuilder Assembly with all kinds of things inside it, use Reflector to learn where things were put and how they were structured, and then use .NET Reflection API calls to get a directory of them at runtime. Once I had the directory of names, I'd let PowerBuilder .NET do its standard magic to dynamically create them at runtime.

I created a PowerBuilder .NET Assembly with everything in it but the kitchen sink (Figure 1 shows my all-time favorite ice cream sundae: Jahn's Kitchen Sink. It could satisfy six hungry kids!). Figure 2 shows the Solution Explorer view of my assembly. It has a function, structure, DataWindow object, menu, CVUO, SCUO, Window and a .NET enumeration. I also added an image file with a Build Action of ‘Embedded Resource.' My plan was to plunge into the assembly's bowels, locate my classes and write code to dynamically build a directory listing of their names that I could present in my UI.

Figure 1: Kitchen Sink Ice Cream Sundae

Figure 2: Shared Assembly

I built a PowerBuilder assembly from my target and used Reflector to examine the assembly structure. Figure 3 show the contents of the disassembled assembly's default namespace. For the screenshot I aligned its generated .NET classes next to their PowerScript Explorer view counterparts. Notice that for each PowerScript Class there is a correspondingly named .NET class prefixed by C__. These C__ classes are the .NET implementation classes. There is also a class named PBGlobalDefinitions_sharedobjects (the target name prefixed by PBGlobalDefinitions_). A look inside this class as shown in Figure 4 reveals that it is a wrapper for the PowerScript class identifiers declared to be of their corresponding C__ class types. This class lists some of the members of our PowerBuilder runtime assembly, but where are the DataWindow Objects?

Figure 3: External vs. internal assembly view

Figure 4: External vs internal Global Type view

A little more poking around with Reflector revealed their location. Figure 5 shows that the engineers tucked DataWindow Object syntax in a local folder named Resources, together with WPF XAML and embedded assembly resources.

Figure 5: DataWindow location

Building the Plumbing
Armed with the knowledge I gained using Reflector about where the global type names were stored, I was able to use methods from the.NET Reflection API to write code to extract global type names from the PowerBuilder assembly. Listing 1 shows the code I wrote to populate a drop down selection list

Listing 1: Extracting Class Names
Assembly myAssembly   //some declarations
System.@Type  types [ ], atype
FieldInfo pbfields[], pbfield
myAssembly = Assembly.LoadFrom(lpath)   //lpath holds the folder/file name of
integer i_upper, x, i_innerctr, y
types = myAssembly.GetExportedTypes() // Get an array of the types in the assembly
for x = 1 to types.Length   //iterate the array looking for ‘our man'
atype = Types[x]
if Left (atype.FullName,20) = 'PBGlobalDefinitions_' then //if are you're "PBGlobalDefinitions_" let's look inside you
pbfields=atype.GetFields( )
for y=1 to pbfields.Length
pbfield=pbfields[y]     //add the global ref name to the DDLB
if not pbfield.IsStatic then ddlb_visuals.AddItem(pbfield.Name) 
end if

Writing code to extract the DataWindow object names was an interesting challenge. It turns out that sharedobjects.g.resources stored in the Resources folder is a collection object. Using some code examples I found on the web as my guide I was able to write the code shown in Listing 2 to populate a dropdown listbox with the DataWindow object names.

Listing 2: Extracting DataWindow names
System.Resources.ResourceReader _rreader
System.Collections.IDictionaryEnumerator _enum
string sResource         
long lrow
_rreader =        Create System.Resources.ResourceReader (myassembly.GetManifestResourceStream("sharedobjects.g.resources"))
_enum = _rreader.GetEnumerator()
do while _enum.MoveNext ( )
sResource = _enum.Key.ToString()
if Right(sResource,4)='.srd' then                    //we got a dwo name!
sResource=Left(sResource, Len(sResource) - 4)
end if
catch (System.Exception e)
MessageBox('woops', e.Message)
end try

The sum total of these two code listings is roughly equivalent to the Classic LibraryDirectory( ) function. Although we are now much richer for the experience, I can't help but think, "Gee whiz wouldn't it have been good if the product engineers would have provided AssemblyDirectory( )functionality?"

An Example: Putting It Together
For my .NET snap-in API I took a decidedly .NET approach. Rather than providing common ancestors and implementing an inheritance-based approach, I decided to provide a common interface that each snap-in class would implement as a kind of marker that indicated the developer had done due diligence in conforming to the interface. In this simple example I only gave the interface one function; in a production application the interface would define many more functions all of which would need to be implemented to fulfill the snap-in contract. Using an interface-based approach allows a snap-in developer to choose class ancestry from among a range of choices. I put my interface in a separate PowerBuilder assembly target that I built and added as a reference to both the snap-in and dynamic loader targets. Figure 6 shows my SnapCommon assembly.

Figure 6: SnapCommon assembly

Listing 3: Testing the interface
ClassDefinition cdo
PowerObject lpo
int rc
lpo = create using  ddlb_visuals.Text  //create the object non-visually
cdo = po.ClassDefinition       
try  //check if the object implements the snappable interface
rc = lpo.dynamic init_snap( 5 )  //all snap-ins must implement this method
catch (RuntimeError r )           //if the method ain't there, it ain't a legal snap-in
MessageBox('Interface Error', 'Snap-In does not implement the i_snappable interface')
rc = -1
destroy lpo
end try
if rc=-1 then return

To determine if the selected snap-in is value, we create the object non-visually and try to call the method define in the interface. If the method isn't there, we'll catch the runtime exception, show a message and quit. If the method is there (we have a valid snap-in), we'll use PowerBuilder reflection to determine its type and then create it using its type correct open function; Listing 3 shows that code. Please note that PowerBuilder reflection was not enhanced to report on .NET types, therefore we cannot use the ClassDefinition object to determine if an interface is implemented by a class. It is possible to use .NET reflection as shown in Figure 7 to determine if an interface is implemented. To do so we'd have to get the implementation class and then reflect inside of it using the PowerBuilder mangled names. However, because it is less code and a ‘pure' PowerScript approach, we chose to take a dynamic approach. Listing 4 shows the Choose Case decision block for opening a class based on its type.

Listing 4: Choose Case decision block
String mytype
mytype = cdo.DataTypeOf
choose case mytype
case 'userobject'
rc = parent.openuserobject( uo, ddlb_visuals.Text, 10, 10)
if rc = -1 then
parent.Title='Open User Object Failed'
parent.Title='Open User Object Succeeded ' + string(rc)
end if
if IsNull(rc) then parent.Title='Open User Object Returned NULL ' + ddlb_visuals.Text
case 'window'
Window w
Open( w, ddlb_visuals.Text)
case 'datastore'
n_ds lds
lds = create using ddlb_visuals.Text
lds.dynamic of_load( sqlca )
end choose

Incidentally, creating DataWindows required the most trivial coding. Listing 5 shows the three lines of code.

Listing 5: Displaying a DataWindow
dw_dwos.dataobject = ddlb_dwos.Text
dw_dwos.SetTransObject( sqlca )
dw_dwos.Retrieve( )

Figure 7: .NET Interface location

Suggestions for Improvement: Most Needed & Nice to Have PowerScript Features
First, the ability to declare namespaces and put PowerScript classes into them is one of the useful .NET CLR language features added to PowerBuilder. Open( ) functions support namespaces when they are statically hardcoded. For example Open(elearnIT.w_testwindow) compiles and operates properly. However, my experiments revealed that the language does not support using namespaces in dynamic Open functions and Create Using statements. For example both Open(lWindow, "elearnIT.w_testwindow") and Open(lWindow, "elearnIT_w_testwindow") fail. This lack of support could be a major impediment for enterprise vendors who would likely instruct their independent software vendors to put their third-party assemblies into a customer-specific namespace in order to guarantee name uniqueness in a multi-vendor application snap-in environment.

Second, even though I wrote code to show how one might get directory listings of an assembly's contents, having native functions such as AssemblyDirectory and AssemblyDirectoryEx would be helpful.

Third, it would be useful to extend the PowerBuilder reflection API to report on .NET types present in a PowerBuilder class.

Fourth, it would be useful to be able to statically reflect on a PowerBuilder Class without having to create it first as a PowerObject.

With a good understanding of PowerScript and .NET reflection, coupled with knowledge of polymorphic coding techniques, a developer can design and implement dynamic and creative solutions to expand the usefulness of their enterprise applications.

Long Live PowerBuilder!

More Stories By Yakov Werde

Yakov Werde, a 25 year IT industry veteran, is a member of TeamSybase and the newly formed Sybase Customer Evangelist Team. Yakov is a recognized author, speaker and trainer who has been designing and delivering PowerBuilder, .NET, EaServer, Web App Development, and Java training for over 14 years to corporate, military and government developers. Prior to discovering his aptitude as an educator, Yakov worked as an architect, project manager and application coder in the trenches of application software development. Yakov holds a Masters in Education with a specialty in instructional design for online learning from Capella University and a BS in math and computer science from Florida International University. Yakov, managing partner of eLearnIT LLC (, authors and delivers workshops and web based eLearning tutorials to guide professional developers toward PowerBuilder Classic and .NET mastery. Follow Yakov on Twitter as @eLearnPB

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.