Paul Harvey, the great American radio personality, would always conclude his colorful broadcasts with the quip "And now you know the rest of the story." For those of you not acquainted with Paul's broadcasts, here's a sample. If you get to about 3:40 in, you'll hear the classic remark. Paraphrasing Paul's tag line, in this article you'll learn "the rest of the story" about RAD Development methodology in PowerBuilder 12.5 .NET using a Referenced PB Assembly Target. I'll explain the technique and implementation steps using 
the open source PEAT PFC demo application.
In a previous PBDJ article, "Slicing the Pie with PowerBuilder .NET 12.1 EBF Project Partitioning," I wrote about achieving Classic RAD-like build/test speeds in .NET WPF applications by configuring the Project object partitioning feature. This feature lets you logically carve up a large application into a small manageable-sized executable with a set of related PowerBuilder assemblies that are automatically generated at full build-time via the Project Object. Although, once configured, you can benefit from RAD speed incremental compiles when making changes to your non-framework code, this approach has several disadvantages. First, it can take a lot of developer time, knowledge of the application and several trial and error attempts to configure the feature. Second, since both the framework and the concrete application are in the same target, an inadvertent save to a framework object will cause a full build on the entire application to occur. Third, a flaw in the incremental compile process causes a bunch of meaningless compiler errors to be reported when changing code in a visual object. The only way to clear the situation is by doing a full build (thereby giving up all compile time advantages).
Recently, I successfully implemented a target-based partitioning approach to PFC-based applications that alleviates compiler-dependency checking and logical application partitioning. I believe this approach can also be applied to non-PFC frameworks. This approach offers several advantages:
- No need to mess with dependencies.
- No need to reorganize code objects based on dependencies.
- No need to locate globals at the end of the dependency tree.
However, since in our universe nothing is perfect, there are two minor disadvantages:
- The entire framework must go into a single assembly.
- You'll need to add a single global function to your framework to set values for framework globals.
Let me now take you through the implementation steps. For illustration I'll use the PEAT demo application that is included in the PFC open source framework.
Preparing the Main Application
I assume you've migrated your PEAT application to PB 12.5 .NET and are able to full build it with no errors. I also assume that you have dealt with (or are temporarily ignoring) unsupported features warnings in your application code. PEAT does not present any compiler errors. For now you can ignore the 450+ warnings that come from the PFC. For the majority of applications they are innocuous. You can turn off the warning messages by checking the "Suppress unsupported feature warning" check box in the project object as shown in Figure 1.
Figure 1: "Suppress unsupported feature warning" check box
Once you have successfully done a full build on your application, remove all the PFC libraries from your application library list. Figure 2 shows a Solution Explorer view of the PEAT PFC sample application after removing the PFC. It has only one library.
Figure 2: Solution Explorer view of the PEAT PFC sample application after removing the PFC
Creating the PB Assembly
The next step is to turn your PFC framework into a stand-alone PowerBuilder assembly. Here's how:
- Create a folder that will be the root your new PowerBuilder assembly Target.
- Move all your PFC library folders so that they are subfolders of this the Target root folder.
- Use the .NET IDE to create a new PB Assembly Target (I named mine PFC). The new PBLx created by the Target wizard (I named mine pfc_wip) will hold your project object and the one special code object you'll need to create (see below).
- Add the 10 PFC libraries to the library list (I ordered the PFE libraries at the top of the list followed by the PFC libraries). Figure 3 shows what your PFC Target should look like.
Figure 3: PFC Assembly Target
- Next, open the PB Assembly Target Application Object in the editor. Change the data types for Transaction, Error and Message to n_tr, n_err and n_msg, respectively. Add a global variable of type n_cst_appmanager named gnv_app (yes gnv_app is used inside the PFC itself!). Save your work
- Lastly, you must create a global function (I named mine f_set_globals) in the first library of your assembly target that will set values for the global variables common to both the PFC and the application. Notice the four parameters and a return type of (None). Implement the function to set the global variables to the parameter values. You can see my implementation in Figure 4.
Figure 4: Global variable initialization function
Now you can full build the PFC Assembly. There should be no errors, just unsupported feature warnings. As a reminder you can suppress those unsupported feature warnings from inside the project object. Once you have a successful build, open the Project Object and jot down the path to the .out folder containing the generated Assembly. If you're going on to the next section immediately, copy the path and file name to the clipboard.
Attaching the PFC Assembly to the Main App
To hook up your assembly to your application, you'll have to follow two steps. First, you'll need to add your new PFC assembly to your application as a reference. Right-click on the References section and choose Add Reference. Browse to the folder that contains your PFC-generated assembly (DLL) and select the assembly. (Or just paste in the path/filename you copied in the Target project object in the prior step.)
Next, you'll need to call the new global function you added to your PFC assembly to set values for the assembly globals. Open the application object in the main app. Immediately after the line of code that instantiates the app manager, add a call to the global function you just added to the PFC, passing gnv_app, sqlca, error and message as parameters.
Now you can do an incremental build. It should only take a few seconds, voilà. Done!
Reaping the Benefits
To do a RAD cycle incremental compile cycle following a few visual or non-visual code changes on this now small app now takes about 15 seconds!!! Happy PowerBuilder (.NET) coding!