PowerBuilder – ‘Plug in’ Applications

Posted on Friday, July 9th, 2010 at 8:38 pm in

I helped develop a special order processing application which was both a stand alone application as well as a ‘plug in’ into a couple of existing apps. By ‘plug in’ I mean the same windows and functionality was brought into the existing applications without any significant changes. Part of the trick in doing this is in the set up of the application libraries (.PBL files).
All of the applications were MDI.

The application library list had evolved over time into the following generalized pattern:

app.pbl > target, project, frame menu, application manager (PFC based) and frame
window.pbl > all windows
dataobject.pbl > dataobjects
service.pbl > general service type objects with limited business rules
business.pbl > objects pertaining to business rules
report.pbl > report dataobjects
everything else including PFC libraries

In the order processing application the only change to the pattern was to move the frame menu into the window.pbl. Each of the other targets had their library lists modified to include the window, dataobject, service, and business PBLs from the order processing app. One thing to keep in mind with this process is you cannot duplicate object names. In this case I used a two letter designation for each app and included it in the object name (ie, w_yy_main).

Since these were PFC based applications I had to override some functionality. In the open events of the Order Processing application windows I overrode the ancestor of the Open event and placed the following code:

// override ancestor
integer li_rc
MENU       lm_WindowMenu
string ls_app
ls_app = gnv_app.of_getappname()
IF (ls_app = 'CPRS') THEN
	lm_WindowMenu = CREATE USING 'm_cpr_frame'
	li_rc = this.ChangeMenu (lm_WindowMenu)
IF (ls_app = 'BRCOST') THEN
	lm_WindowMenu = CREATE USING 'm_main'
	li_rc = this.ChangeMenu (lm_WindowMenu)
super::event open()

This allows for the windows to have separate menus based on the application they are running in. In the above code, if the Order Processing app was running it would use its own menu, otherwise it would use one of the other app menus. The Order Processing windows had mostly self contained functionality. By this I mean they had save, cancel, retrieve, etc. type buttons on them and did not make use of menu commands. You could build in menu commands but I didn’t have the time on this particular project. The apps also connected to separate databases (three total) which were handled by separate transaction objects.

One thing to keep in mind about this type of approach is that any code changes to the common objects in the Order Processing application necessitated a rebuild of the other applications which made use of them.