Mastering PowerBuilder

Getting Your Bearings

In this session, you will be re-creating "Product Management System" application using PFC. At the same time, you will learn about PFC internals. We assume that you have completed exercises that were given at the end of "User Objects" and "Advanced DataWindows" sessions. We will use the existing DataWindow objects. Instead of creating an entirely new application, we would be adding a new PowerBuilder library and create all new objects in that library. This allows us to test the application progressively as we create it. Initially, you will be doing few things without even understanding why you are doing it Bear with us, we will explain it after the basic setup.

• Create a new -library, pfc-product.pbl.
• Open the application painter and make pfc-product.pbl the first library in the library list.
• Append the following libraries to the application�s library list in the order specified below:
• PFEMAIN.PBL
• PFEAPSRV.PBL
• PFEDWSRV.PBL
• PFEWNSRV.PBL
• PFCUTIL.PBL
• PFCMAIN.PBL
• PFCAPSRV.PBL
• PFCDWSRV.PBL
• PFCWNSRV.PBL
• PFEUTIL.PBL

As you know, we are using a user-defined transaction object instead of the standard transaction object. PFC has it�s own transaction and error services. Let�s use them instead of our transaction service.

• In the application painter, set the SQLCA global object to inherit from n_tr.
• Set the ERROR global object to inherit from n_err.

We have a non-visual custom class object that provides the application level services, such as login process, error service, transaction service, etc. In each event of the application object, we have some code. What we need to do is, get rid of that code and redirect the processing of each event to the event that is available at the application service. Before you do that, you need to declare the application service object as a global variable. This will be the only global variable we will be using in the whole application.

Why should we redirect the processing. Why shouldn�t we write the code in the event itself. Well, Good question. The answer is definitely not a single line answer. It goes as follows:

Do you agree when I say that an application object can�t be inherited. Even if you disagree keep on reading. When you write the code in the application object itself, and later on try to create a different application and want to use the previous application object's functionality, you have only one choice. That is, copying the code, because, an application object can�t be inherited. As explained above, the application service manager is a non-visual custom class user object. So, User objects can be inherited. In the new application, you can use the user object or create a new object by inheriting from the previous one. With this technique, indirectly you are reusing the application object.

• Declare a global variable as shown below:

n_cst_appmanager gnv_app

• Replace the SystemError event code with:

gnv_app.event pfc_systemerror()

• Replace the Open event code with:

gnv_app = create n_cst_appmanager gnv_app.event pfc_open(commandline)

• Replace the Idle event code with:

gnv_app.event pfc_idle()

• Replace the Close event code with:

gnv_app.event pfc_close() destroy gnv_app