Home
What's New
Dev Tools
Services
Feedback
Site Map

PowerBuilder Foundation Class (PFC) Introductory Topics:

A Brief Overview of PFC

The PowerBuilder Foundation Classes (PFC) were introduced with PowerBuilder 5 and enhanced in PowerBuilder 6. PFC is a set of PowerBuilder objects that provide the basis for developing robust PowerBuilder applications. PFC objects provide a consistent framework that can be used across PowerBuilder applications. PFC libraries may be customized or extended to enhance the existing PFC functionality. The libraries also include useful non-application routines, such as debugging and SQL trace objects.

PFC was written using PowerBuilder and delivered as PowerBuilder objects with supporting PowerScript source code. PFC uses advanced PowerBuilder object-oriented coding techniques and features a service-oriented design.

PFC uses windows, standard class user objects, and custom class user objects to implement an object-oriented design by isolating related types of processing (such as DataWindow caching, row selection, and window resizing). These related groups of processing are called services.

Why Use PFC?

PFC provides a great deal of logic in ancestors and services. Having this pre-built code provides a number of benefits:

PFC Architecture

Early frameworks often used a "pure ancestor" approach where all the common logic was placed into ancestors. Frameworks like PFC use a hybrid approach where some functionality is provided in ancestor objects while the majority of logic is placed into services. The pure inheritance based approach suffers from these disadvantages:

A service-based approach places functionality into a non visual (or custom class) object. Objects like a Window (or DataWindow) may break down their functionality so that there is a main Window object which has 10-20 supporting services available. Various services are turned on (i.e. loaded into memory) when the descendant object specifically requires the functionality. The descendent object then specifically uses functionality provided by the service.

With logic broken into user objects (which are loaded as needed), the service based approach avoids the problem of "fat" ancestors where very large ancestor objects must beloaded into memory (and have only a small portion of their functionality actually used). Each service that is used does inflict a small performance penalty since the service must be separately loaded into memory at runtime. Another key benefit of service-based objects is that they are more easily reviewed and maintained since each service is a logical bundle of related functionality.

PFC uses a combination of ancestor objects and services. Logic that is very commonly used (e.g. CloseQuery) is simply placed into ancestor to avoid service loading overhead. On the other hand, the bulk of the functionality (which is used only on occasion) is placed into services.

Extending PFC

No pre-developed class library can meet all the needs of a development project "out of the box". PFC offers an extension (or PFE) layer which allows for customization of PFC without modifying the underlying PFC code itself.

PFC implements an extension level in all its inheritance hierarchies. These extension objects reside in separate PBLs so that they are unaffected by PFC or PowerBuilder upgrades. The extension objects have access to all instance variables, functions and events in the PFC ancestor library. Literally any functionality in any object can be extended or overridden, if needed. PFC Extension Strategies are discussed else on this site.

Suitable Projects for PFC

PFC could be used on the majority of PowerBuilder projects and be very helpful. There are a few kinds of PowerBuilder project where PFC might not be suitable:

  1. A small project (e.g. 10 windows or less). When using PFC, there is certainly overhead in terms of learning curve, EXE/PBD size, etc. If you are only going to develop only one or two small applications, the costs of PFC would outweigh the benefits. Incidentally, if you only have a small project or two, then Visual Basic (VB) would probably be a better choice than PowerBuilder. VB is "easier" to use for small projects and it creates smaller executables. VB starts to become the weaker choice on medium-sized projects and VB is just not the right tool for large projects where PowerBuilder excels.
  2. PFC version 5 doesn't work easily with 3-tier/n-tier architectures. By default, PFC issues updates directly to the database (assuming the two-tier model) and it takes some serious investigation and overriding to make PFC suitable work in a 3-tier model. PFC version 6 introduced self-updating objects which should provide a much more natural method for creating 3-tier applications.
  3. If your project has a number of unique/non-standard requirements (particularly related to the user interface), you might find that PFC doesn't meet a number of your requirements. Although PFC can be extended, you might find that another framework provides a better fit for how you are trying to build your application.

Listing of PFC Services

A overview list of services provided by PFC is provided below.

Application Services:

Window Services:

DataWindow Services:

Other PFC Services

Steps in Creating a PFC Application

Sybase may still have documentation on the steps needed to create the PFC layer (the last known location was moved).

Still Having Trouble Understanding PFC?

The truth is that if you haven't worked with a framework before (e.g. an earlier PowerBuilder framework or possibly a C++ framework), it is difficult to fully appreciate the "value" and the amount of work you save by using a framework. Consider the following sources to improve your understanding of PFC and its benefits:

If you decide to use PFC, you should seriously consider using version 6 -- it comes with the PowerBuilder 6 Enterprise edition. The documentation with PFC 5 was spotty and it is greatly improved in PFC 6.


Copyright Woodger Computing Inc.