Mastering PowerBuilder

HomePrevious Lesson: Course 3:: Session 24 :: Page 70
Next Lesson: Course 3:: Session 24 :: Page 90
Getting Your Bearings

In this session, you will be re-creating "Product Management System" application using PFC. At the same time, you will also learn PFC internals. We assume that you have completed exercises that are given at the end of "User Objects" and "Advanced DataWindows" sessions. We will be using the existing DataWindow objects. Instead of creating entirely a new application, we would be adding a new PowerBuilder library and create all new objects in the new 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 have to do those. Bear with us, we will explain once you make the basic setup.
Create a new -library, "pfc-product.pbl".
Open the application painter and make "pfc-product.pbl" is 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
PFCMAIN.PBL
PFCAPSRV.PBL
PFCDWSRV.PBL
PFCWNSRV.PBL
  As you know, we are using a user-defined transaction object instead of a standard transaction object. PFC has it’s own transaction and error service. 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 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 the application service object as a global variable. This would be the only one global variable we will be using in the whole application.

Why should we redirect the processing. Why I shouldn’t write the code in the event it self. Well, Good question. The answer is a little long.

Do you agree that application object can’t be inherited? When you write the code in the application object it self, and later if you want to create a different application and want to use the previous application object functionality, you have only one choice. That is copying the code, because, application object can’t be inherited. As explained above, the application service manager is a non-visual custom class user object. User objects can be inherited. Do you get the answer? In the new application, you can use the user object or you can 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

HomePrevious Lesson: Course 3:: Session 24 :: Page 70
Next Lesson: Course 3:: Session 24 :: Page 90