Application manager is the replacement of the application object. Because the application object cannot be inherited, PFC has chosen to use a non-visual object to replace it. This was accomplished by redirecting all the application object events to the application manager object.
Application manager serves as a container for the many functions and properties requiring global access. These properties include application and user INI file locations, reference to the frame window, help file location, registry key path, application version, title and bitmap.
Application manager is also unique in a way that it serves both as a service provider and requester. The application manager acts as an anchor for the services that are persistent throughout the life of the application an have to be referenced by other objects and services. These include:
- Transaction Registration
- Datawindow Caching
- Debugging
- Error
To use the PFC logon one needs to be familiar with the three key methods.
of_logondlg() is a function that triggers the logon sequence.
n_cst_appmanager pfc_logon is a placeholder event, which should contain logic to connect to the database using the as_userid and as_userpassword arguments.
The function is typically called from pfc_logon event. PFC provides the logic to connect to SQLAnywhere ODBC datasource. If a different DBMS is used the function should be extended to provide the appropriate logic.
If you plan to extend the logon window or modify the logon process it is important to understand what happens "behind the scenes" when the of_logondlg() function is called.
1. The logon process is started by calling the of_logondlg() n_cst_appmanager function.
2. of_logondlg() triggers the n_cst_appmanager pfc_prelogondlg event
3. pfc_prelogondlg event reads the registry or the INI file and restores the previously stored values for the user id. It also sets the values for the applcation display name and the application logo as specified in the applcation manager.
One way to customize the logon window is to extend the pfc_prelogondlg event. The event accepts an "attribute" autoinstantiated NVO (similar to a structure) inv_logonattrib.
Out of the box you can modify the user id, password, the application logo, and the application name. You can extend the object to add additional instance varibles, which for example may allow you to modify the window size or position.
4. of_logondlg() opens the w_logon window, passing it the "attribute" object inv_logonattrib. Note that w_logon window is opened by directly specifying it's class name. This means that if you extend the logon window by inheriting from w_logon and generaring w_my_logon the changes will be ignored by PFC. If the extension layer is used for the application logic you can modify the w_logon directly. If an additional corporate department layer is available you can modify corp_w_logon or dpt_w_logon. As long as the w_logon is the last descendant in the inheritance chain PFC will be happy. See the Extension strategies article for more detailed discussion on this topic.
5. pfc_w_logon window open event sets the logon window attributes as specified in inv_logonattrib. If the user id and the password are passed they are populated as well.
6. The user presses the < OK > button, which triggers the pfc_default event on w_logon.
7. pfc_default event attempts to logon to the database by triggering the application manager pfc_logon event. If the logon is successful the password and ID are passed back to the of_logondlg() function.
8. n_cst_appmanager pfc_logon is a placeholder event, which should contain logic to connect to the database using the as_userid and as_userpassword arguments.
9. If the logon was successful of_logondlg() function saves the user ID in the registry or the INI file.
This problem occurs when the splash an the logon windows are opened from the same event. The workaround is to place them in different, posted, events (pfc_open, pfc_postopen) or adding a Yield() between the logon and the splash windows.
Both of these problems may be related to the fact that of_SetUser() in pfc_n_tr only populates the UserID and DBPass transaction properties in versions 5.0.00 and 5.0.01 and DBParm in 5.0.02. Many other databases require LogID and LogPass to be populated as well.
The quick solution is to extend or override the of_SetUser() in pfc_n_tr by creating the same function in n_tr and adding the necessary assignments:
- Super::of_SetUser(as_userid, as_password)
- this.LogID = as_userid
- this.LogPass = as_password
Another solution is to create a DBMS specific transaction n_tr_sybase, n_tr_oracle, etc... by inheriting from n_tr.
Third method is to create a transaction service. Stay tuned for more details...
Contributed by PFCGuide staff, except
where noted otherwise.
PFCGuide is sponsored by Dynamic Technology Group
The information provided is for advice only and not to be considered a contract or a
liability against Dynamic Technology Group.
Last revised: February 15, 2004 03:58 AM.