What's New
Dev Tools
Site Map

Suggested PFC Extensions

As indicated by PowerSoft itself, few (if any) applications will use PFC "right out of the box". PFC provides a very good base on which to build but it does not include all possible generic and reusable code that an application might need. For this reason, any project needs an extension layer to provide additional generic capabilities as well as additional capabilities that are specific to the application being developed.

General strategies and architecture advice for extending PFC are provided on this site. This page deals with specific functional extensions.


The purpose of this page is to provide a list of PFC extensions that you might consider when architecting (or extending) a PFC-based infrastructure. Keep in mind that this is a list of suggestions and some may be applicable to your organization while others may not apply.

PFC Extension Functionality to Consider

Typical extensions that could be considered for PFC are broken into the following categories:

New Visual Objects

PFC provides a number of generic "visual" objects intended to serve as ancestors for application windows (sheet window, response window, command button). However, with a few notable exceptions (e.g. Logon window, generic Sort window), PFC doesn't provide visual ancestor application windows. PFC's decision not to supply visual ancestors is largely understandable -- there are many ways to build an applications and many philosophies about what is better and worse. PFC doesn't want to try to impose a particular GUI design on the many end-applications that use the framework.

When creating your own extensions to PFC, you don't have the luxury of not "commiting yourself" to any particular GUI design philosophy. There are several good reasons for creating visual ancestors which impose a GUI design on your PFC extension layer:

A typical project could consider the following standardized visual objects ancestor windows (i.e. extensions to PFC):

Each of these visual ancestors is below. In addition, you can find specific suggestions for defining visual ancestors.

Search / Results of Search Window(s)

Most business applications need to capability to search for an object, based on predefined search criteria and display the rows that match the criteria. This search ability generally needs to be built for every major business object (with different criteria and results of search criteria for each object).

If you are not using PowerBuilder's standard Query By Example (QBE) capability, then three broad visual approaches might be used to provide searching capability:

Format Advantages Disadvantages
Format 1: one window with one list DW.

Allow the user to enter the search criteria right into the "results of search" list. Matching data is displayed in the same list.
- simple window appearance - only data that is displayed can be used to search
- search criteria "disappear" when search is invoked
Format 2: one window with an enterable DW and a list DW.

Allow the user to enter search criteria in a separate DataWindow at the top of the window and display results below.
- the user can see search criteria and results in one place - if there are many search criteria / search options, there may be little room to see the results
Format 3: two windows: one for criteria and other for results

Have a pop-up response window where the users enters search criteria. After the search is initiated (user hits OK), then the response window disappears and the application display the results in a "results of search" list sheet.
- lots of space to enter search criteria (on pop-up window) and a window-full of results are listed
- with ample space, it can handle the most general searching requirements
- pop-up search criteria window can be reused with Lookup window (below)
- more complex interface (two windows)

Generally speaking, it is advisable to select a single search approach and use it consistently throughout the application. This will provide more consistency for users and it will require less code be written and maintained by the team.

Some standard functionality that can be included in the search (or search/list) window ancestor(s):

PFC functions (like DataWindow sorting, filtering and row selection) can be invoked to help the user manipulate the results of search list.

Lookup Window

What is a Lookup Window

When entering Detail data, users are accustomed to being provided with a drop down list (or drop down datawindow) which lists the possible values for the column they are entering. Unfortunately, when there are more than 50 possible values, the dropdown list is a poor display mechanism since it forces the user to do a "linear" search of the data.

Consider an Order Entry window where the user has to specify the customer. There may be 100,000 possible customers. Clearly, the user needs the ability to enter search criteria to limit the data displayed and resorting of results could help too. In old-fashioned systems, the user would have had to write down the customer number and type it into the Order Entry window.

In a "good" Order Entry window, the user would press the dropdown arrow in the Customer column to find the Customer (alternatively, the user might press right-mouse and choose a Lookup right mouse menu item). A modal (response) Lookup window would then be presented where the user could enter criteria (e.g. customer name, phone number, etc.). The matching customers would be displayed in a list. From the list, the user would select the correct customer and the resulting Customer Id would be returned to the Order Entry window.

Lookup Window Capabilities

The capabilities provided by the Lookup window are very similar to that of the Search / Results of Search list window. However, there are differences. In an MDI application, the results of search list would be a sheet while the Lookup is more suitably a response (or modal) window. Also, a number of non-essential actions (e.g. printing, opening a detail, creating a new object, etc.) would be excluded from the Lookup since these operations have nothing to do with finding the object.

Tree Window

PFC provides a fairly comprehensive treeview ancestor/service. However, there can be several useful capabilities implemented in a Tree List or Tree Detail ancestor:

Depending on how a tree is used in your application, you might find it useful to build an ancestor Tree Window to support your specific requirements.

Detail Window

A Detail window is a window that shows the details of an object in one or more DataWindows. Standard Detail Window functionality could include:


Tab Detail Window

The window described in this section assumes that a large object is being maintained through use of a tab object (which contains several tabpages).

Standard layering for a tab window in PFC is as follows:

It is good from an encapsulation perspective to build the Tab Detail Windows in four layers like this. Tabpages are built independently of each other and the Window doesn't get overly complex as a result.

The challenge is that much standard communication is needed between the layers, such as:

1. The tabpages and DataWindows might need to obtain the following information from the Window-level:

Note: this information was probably obtained during Window opening but it might change as the user performs actions. The TabPage probably needs to call standard Window functions to access the "latest" values.

2. The Window needs to tell (or ask) the Tabpages and DataWindows about the following:

3. The Tab control needs to tell the Tabpages and DataWindows about the following:

If this logic is placed into standard functions/events that the ancestor automatically invokes/manages, then it is much easier to build and manage each descendant Tab Detail Window.

Wizard Window

An ancestor wizard window could be created that included previous/next buttons. The ancestor would manage the movement between these adjacent windows and it might provide the capabilities suggested under the Detail Window ancestor.

Error Search/Maintenance Windows

You will need to develop your own windows to search for error message and update them. PFC does not provide message search/maintenance windows for you.

Extensions to Specific PFC Services

Various extensions that your might consider to PFC Services are provided under the following headings:

Logon Window (w_logon)

The standard PFC logon window lets the user exit the logon without actually logging on. You might want to shutdown the application, if the user exits the logon window without logging on. Also, PFC doesn't allow for retries on the logon window. You might want to allow for the standard three retries and then shutdown the logon window, if the user has three failed attempts.

DataWindow Extensions (u_dw, etc.)

There is plenty of opportunity for writing reusable DataWindow capabilities, on top of the rich PFC DataWindow function set. Suggested DataWindow extensions are given below.

Standard u_dw Events:

Callable DataWindow Functions:

TreeView Extensions (u_tv)

Transaction Object Extensions (n_tr)

Error Service Extensions (n_cst_error)

Aside from having to build your own windows to search/maintain messages in the Messages table, you can make a few useful extensions to the message service:

String Service Extensions (n_cst_string)

New Services To Create

The new services below could be useful in augmenting PFC's functionality for your application.

Array Service

PFC lacks an array service so you might want to develop one. Many of array functions could apply to several data types (e.g. numerics, strings, dates). Some useful array functions would include: Sort Array, Find Array Element, Add Array Element, Remove Array Element, Remove Duplicate Array Entries, Sum up Array Elements and Check if Arrays are Equal.

Variable Service

Aside from the above array service, there are a number of standard functions that apply across variable types (and you might want to create "overloaded" functions to handle the major variable types). The main purpose of the functions listed below is to avoid the standard nuisance of constantly checking if variables are Null or something else, which is a common PowerBuilder coding issue. Specific null side-effects are discussed more fully on another page.

Note: When you get in the habit of using functions like those above, you rarely run into a situation where "unexpected" Null conditions cause your logic to fail.

Required Column Service (not PFC's)

Sample Required Column Service Design

Miscellaneous Support Functions

Advanced Services

A number of more advanced services that would augment PFC are presented in this section. These services would require more effort and more sophistication to develop. As such, they would be more suitable for larger organizations. The extensions are presented under the following headings:

Menu Services

Window Services

Help Services

Copyright Woodger Computing Inc.