|
|
Appendix J - 
pfc_w_master
by Sharon Weinstrom Buntz
Here’s what we’ll cover in this appendix about pfc_w_master …
What is
Why understand
Which of these six window type descendants of
Would I ever customize my
Would I ever customize my
Two Big Pictures of
What does
Tell me more about everything in
Instance Variables
Functions
Events ... Note: This section was too big to be included in this same web page
Tell me a little about
OtherAnd what about the changes to
PFC 6.0 Release ?
Summary
About the Author
pfc_w_master is the Top-Most Ancestor of ALL windows
in the PFC;
"Great, Great Grandpa" of ALL PFC Windows.
Think about that for a minute…
That means that there is a family tree for five generations (at least),
and so there are a lot of family members under Great, Great Grandpa!
Figure 1 - pfc_w_master is the "Great, Great Grandpa" of ALL PFC Windows
Using the PFC, ALL of your windows will descend from pfc_w_master.
So that means that every single window in your application is affected by what pfc_w_master does.
All of the main "plumbing" of the PFC’s
"framework" is included in pfc_w_master.
It has to be there for the PFC to work properly, re-routing events of the window to all of
the proper services, other visual objects or other pfc_w_master events. By the way, if you aren’t yet familiar with the concept of
"Service-based Architecture", it would be a good idea to read up on it. Two good
sources for this are:
Powersoft’s white paper on PFC http://www.powersoft.com/products/devtools/pb50/pfcarch.html#overview William T. Green’s white paper on SBA http://www.concentric.net/~Bgcastle/SBA/SBA_Main.html
Next down the chain of ancestry from pfc_w_master is w_master. W_master is pfc_w_master’s
direct descendant, the only direct descendant in fact.
Continuing down from w_master, then descend all of the different types of windows, such as a Frame, a Sheet, a "Main SDI" window, a Response window and so on. There are six of them. Take a look at them in Figure 2. Notice how the descendants from w_master are "higher-level" PFC-level pfc_w_ objects, not just PFE-level w_ objects. Then come the w_<6 types> objects, the ones from which you will inherit all of your application-specific windows. These are w_frame, w_sheet, w_main, w_response, w_popup and w_child.
Figure 2 - pfc_w_master è w_master è six window type
descendants from which you will inherit
This picture was derived from PowerBuilder’s native Browser
Output Documentation… Try it out by pressing the 
PowerBuilder
PowerBar toolbar.
Note 
Take notice how the PFC/PFE/PFC/PFE objects spiral has you walk down the chain of
inheritance. Although we will not go into this in detail, it is important to realize this
early on. This is so that you can understand the regeneration implications
of the PFC objects being inherited from the PFE objects (which normally sounds backwards).
As a PFC programmer, all of your windows will always be descendants of pfc_w_master. (You should never inherit directly from the PowerBuilder Window type in a PFC application.) This is because PFC needs all of the "plumbing" for the PFC "framework" that is provided in pfc_w_master in all of its windows in order to work properly. And that is why it is so important to understand pfc_w_master. Because from him all of your PFC windows descend, and he drives all of the PFC’s objects and main processes..
Understand pfc_w_master, and you shall understand a
lot about the PFC and how to manage all of your windows!
Which of these six window type
descendants of pfc_w_master do I inherit from?
You will always inherit from one of these six window type descendants (or lower) of pfc_w_master: w_frame, w_sheet, w_main, w_response, w_popup or w_child. The type that you select depends on the type of window you want for that particular situation.
If you are using MDI (Multiple Document Interface ~ like PowerBuilder itself does), then w_frame is the MDI frame ancestor, and your application's frame w_<your app>_frame will inherit from him. And w_sheet is the ancestor from which each of your frame's MDI sheets will be inherited from, for example w_se_transcript_maint.
If you are not using MDI, but rather SDI (Single Document Interface), where you don't need a frame with lots of sheets within it, then you would inherit from w_main rather than w_sheet for each of your main windows.
From either your MDI or SDI application, for other types of windows, inherit from either w_response, w_popup or w_child.
So basically, every time you open the Window Painter to create a new
application window, you will select "Inherit", and then you will select one of
these six windows to inherit from - w_frame, w_sheet, w_main, w_response, w_popup and w_child. You may have a need to inherit from a lower level down, but just realize that
you will never inherit directly from either pfc_w_master,
w_master or
PowerBuilder’s native window objects.
Keep in mind, the PFC follows this same scheme with the ready-made windows that it comes with. So, the PFC itself contains some descendants of these six window type descendants. Take for example, w_logon, which is inherited from pfc_w_logon, which is inherited from w_response.
Figure 3 illustrates how to inherit from the six window type descendants for MDI apps and SDI apps. It also shows how the PFC itself contains some descendants from these six window type descendants. Here we are using "se_***" as our naming convention for our application objects.
Figure 3 - You should inherit from these six window types,
such as w_frame è w_se_frame
for an MDI frame.
Note that there are already some PFC objects descending from these, such as w_response è pfc_w_logon è w_logon.
Would I ever
customize my pfc_w_master?
Probably not. You will probably never customize or change pfc_w_master. This is because you should almost never change the PFC-level source directly
yourself. Here are some reasons why…
- For one, it will throw Powersoft’s customer support for a loop. It is probably even written in the support contract that they will not support you if you do so.
- Secondly, sticking to the base will benefit you because then you are in tune with all of the other PFCers out there. So everyone is on the "same page". Also, then you may easily take advantage of other PFC extensions written by others.
- Thirdly, you would normally take advantage of the PFE layer to enhance or correct the PFC level objects. That is why the PFE layer is there, that is its purpose. (Please see the next section for details.)
So only new releases of the PFC would change (actually replace) your PFC PBLs.
Now having said all that, there is one exception to this golden rule.
You may want to change the PFC-layer source code directly if a PFC release has already
come out with a known, existing, official fix, and you have not yet migrated
to that version. (Later, we will show you two specific cases of these, under 
Bug Alert!) Or perhaps Powersoft has announced a patch
or such.
In any case, you would want to document profusely just exactly what you
had changed (see Note below). This is because you would want to
double-check or re-implement any changes that you make to the PFC objects after installing
the new version of the PFC objects. Remember, new releases replace your PFC PBLs. And
remember, these cases where you change the PFC objects directly should be rare anyway.
Would I ever
customize my w_master?
Yes, there are a couple of cases where you may want to customizew_master.
Note
- First case, you might change w_master if you were enhancing the PFC code in pfc_w_master, or making a temporary fix to the pfc_w_master code. In these cases, you would be either extending the pfc_w_master code, overriding the pfc_w_master code, or possibly adding new instance variables, new window functions or new user events. Which leads us to the second case…
- And, secondly, you may have a need to create one or more "empty, placeholder, virtual" events yourself, modeled after how the PFC is designed and written. So you would define these user events in w_master. But still, even in this case, consider whether you really want these new empty events for all of your windows, rather than just a subset, or only for special case application windows. This is because events "fail silently", so they don’t actually have to exist on a window that does not need the special event. But there may be cases where you would want to cover all windows…
For example, perhaps you are in an environment where you always have some particular master or offline process to alert (via a special table) before and after performing your updates, that contains information about your updates.
In this case one might add pre-update and post-update user events to w_master for processes that fall within the Logical Unit of Work processing (as the PFC events that are already there, are processed outside of the database transaction). You might call these new events, say, (ue_PreUpdateInLUW and ue_PostUpdateInLUW) or (ue_TranPreUpdate and ue_TranPostUpdate), just as some examples. It is discouraged to use the pfc_ prefix on your own added user events.
Then, of course, you would have to trigger them in the appropriate place. In our example, w_master’s pfc_update could be overridden, trigger the first new user event, call the ancestor’s event, and finally trigger the second new user event.
And now, all of your windows will have these empty events, ready to be extended in the appropriate descendants. And every window will know to execute them when the time comes.
We might add here though, that in the
Other than those two cases though, usually you would not actually want
to modify w_master
directly. This is because any change that you make to w_master will affect ALL
of your windows since w_master is the ancestor of all PFC windows (other than pfc_w_master). So keep in mind, whenever you add
instance variables, events, and functions to w_master, the changes will impact all PFC windows. And so it follows that you should regenerate
all of your windows immediately thereafter. To reemphasize the impact, when you
regenerate all of your windows after adding new attributes and methods to w_master, you are affecting the
compiled version of all of your windows, including the PFC-level objects. This is due to
the spiraling dependancies between the PFC/PFE/PFC/PFE objects that we touched on in Figure 2 caption’s Note.
But, usually, rather than changing w_master, you would modify one of the six window type descendants (or lower) of pfc_w_master. For example, you would normally just want to change, say w_sheet, to add functionality to all of your sheets, not ALL of your windows.
Two Big Pictures of
pfc_w_master
Let’s take one more look at the window hierarchy here in Figure 4 …
Figure 4 - Another viewpoint of the pfc_w_master relatives
And below, in Figure 5, here’s the "Big picture" from your PFC 5.0.03 Online Help.
This is what we will cover in detail… We will be covering up through the 5.0.03 release with an indicator of 
5.0.0# beside what is new
since 5.0.00.
The changes in thePFC
6.0 Release are drastic enough (and not finalized as of this
writing) to merit leaving them out of this section. It would actually confuse you more
than it would help you to interweave them into here. So we will just focus on 5.0.0#
versions. But don’t worry, to satisfy your curiosity, and to tie in where the PFC is
going with 6.0, we will outline in detail what is projected for the PFC 6.0 Release in the
last section. So, as hard as it is now to say with certainty what will actually be
released in the next version, it is important to try ~ as you will probably be reading
this after 6.0 is out.
Figure 5 - All about pfc_w_master - Check out the PFC Help Often
What does pfc_w_master contain?
Now that we see the big pictures, roll up your sleeves! It’s time
to get down to the technical details and learn all about pfc_w_master…
pfc_w_master contains:
Instance variables to keep track of key information needed for the window,
such as flags, an array of all of the controls on the window which will be updated, a database error string, and all of the instances of the Window Services that are CREATEd when you call the window functions to turn them on.
Functions to access all of the
protected,
as every good Object-Oriented program provides.
(By the way, there are no private instance variables in pfc_w_master.)
specifically the Basic Window Service, the Window Preference Service and the Window Resize Service. Please note that the Sheet Management Service and the Status Bar Service are included in pfc_w_master’s descendant, pfc_w_frame, not pfc_w_master itself.
The key
Pre-coded
Native PowerBuilder events
that automatically handle a lot of the functionality that is needed by all windows. Key native PowerBuilder events, such as the Open, CloseQuery, Close, Resize and Move events, already have PFC code in them to handle basic window processing logic. Most of the code simply "re-routes" the processing off to the proper Non-visual User Object which handles a particular Service’s processing. The CloseQuery is a KEY, important PFC event, so be sure to read up on it below. Also, realize that at the bottom of the Close event, the PFC automatically does some housekeeping for you to turn off (DESTROY) any window services which may have been turned on for that window.
Pre-coded and
Partially-coded+Extendable PFC User Events
that automatically handle a lot of the functionality that is needed by all windows. Key PFC user events, such as the pfc_Save, pfc_MessageRouter, pfc_Help, pfc_MicroHelp, pfc_ControlGotFocus and pfc_Close events, already have PFC code in them to handle basic window processing logic. Some of them, like the Save event, spawns off a whole sequence of other pre-/extendable-/coded and "empty" events to automatically handle the flow of events for you. The pfc_MessageRouter "Message Router" is a special event that will go looking for an object which has a particular user event, and it will trigger the event on the object that it finds. Be sure to read up on the pfc_Save and the pfc_MessageRouter events, as they are KEY, important PFC events.
Note
Take note that on anyThe most common events in this category that PFCers sometimes "extend" are:
These events are often extended in order to have them recognize other controls such as the ListView and TreeView controls… However, please note…
Empty, Placeholder, "Virtual" User Events
in which you are responsible for filling with the proper script.
Note
Take note throughout this document of any of these events which have this
Note
In here you may:
- Turn on any Window Services
- Register the window with the Security Service
- Set your Help ID
- Disable the CloseQuery logic if appropriate
Since this event is triggered at the top of the Open event, you want to limit things done in here until after the Open event completes. That leads us to the next event…
In here you may perform longer-running processes such as:
- Of_SetTransObject( )’s (if no tabs involved)
- Database retrievals
- Other long-running processes
- Things that can wait until this event executes
- Things that may need to close the opening window
Open another sheet, window or file from another sheet herePlease be sure to read up on these and other
Tell
me more about everything in pfc_w_master…
Now that you have an overview of what’s in pfc_w_master, let’s cover each of pfc_w_master’s Instance Variables, Functions and Key Events in detail. We’ll list them all here for your quick reference convenience. And then we’ll take each category one at a time, outlining the particulars of each and every Instance Variable, Function and Key Event.
| Key | |
| |
è Instance Variable |
| |
è Event with PFC script |
| |
è Event with PFC script that you may want to extend |
| |
è Event Placeholder, intended for you to add script to |
| |
è Function |
| |
è Protected: scope |
 |
è Public: scope |
| |
è PowerScript Native |
| 5.0.02 |
è New in PFC Release 5.0.02 |
| Note |
è Breakpoint - Stop and take note! |
| Bug
Alert! |
è Self-explanatory <s> |
| pfc_w_master |
Instance Variables
Shared Variables
< None >
Structures
< None >
Functions
External Functions
< None >
Events
| pfc_w_frame |
Functions
Events
| pfc_w_sheet |
Events
| pfc_w_response |
Events
 Related Objects
to read up on |
pfc_w_master’s Instance
Variables
Instance Variables
Shared Variables
< None >
Structures
< None >
| Instance Variable ProtectedPublic,Type, Name |
What is it? | What is it used for? | ||
|
any ia_HelpTypeID |
Help Type ID for window The ID of the keyword or topic to show for Help for this window |
Tells the ShowHelp function which keyword or topic to jump
to automatically when the user hits F1 for Help from this window. You need to set it in your window if you would like Help to navigate for that window.
|
||
|
boolean ib_CloseStatus |
Status - Closing? Are we in the middle of the closing process at this time? |
PFC sets this to TRUE at the top of theCloseQuery event, and back to FALSE if the close is aborted. Outside
of this window, you may check this flag if you need to know if the user is in the process
of closing via
|
||
|
boolean ib_DisableCloseQuery |
Disable Close Query? Do we want to skip CloseQuery logic when the user closes window? |
If you set this to TRUE, the entire PFCCloseQuery logic will be skipped. Therefore, if the user closes window with a validation
error or has not saved their changes, they will not be asked if they wish to do close or
save. Instead the window should just close. It is helpful to set
this boolean instance variable to TRUE in cases where you know that the window should be
read-only, and therefore no updates should be allowed. This is because the PFC
|
||
|
boolean ib_SaveStatus
|
Status - Saving? Is the window in the process of saving data? |
PFC sets this to TRUE in the pfc_Save event, temporarily around the pfc_Update event
…
Whenever ib_SaveStatus is TRUE, no modal windows should be allowed to open, because we are in the middle of a save transaction. If you are outside of the window, you may call If ib_SaveStatus is TRUE, PFC calls |
||
|
u_dw idw_Active |
Last Active DataWindow control reference | PFC keeps this reference variable pointing to the Last
active DataWindow control for you. Whenever you send a message
from your menu, the "Message Router" has a prioritized list of objects to
attempt to route the message to… One of the last objects in the Message Router’s
list is to check if there is a valid last active DataWindow control reference- IF IsValid(idw_Active). If so, then the You may also use this reference variable to refer to the (current and/or last) active DataWindow control.
|
||
|
n_cst_resize inv_Resize |
Window Resize Service instance | If/when you call of_SetResize (TRUE) to turn on the Window
Resize Service, this instance of the Window Resize NVO is CREATEd so that you and the PFC
may call Window Resize Services. Note: The Resize Service is not only a Window Service. It also services other objects, such as User Objects, Tab Controls, etc. Basically, it services any object that contains a control array of visual objects. Because the Resize Service is really a service to many different objects, not just a window, the Resize NVO is inherited from a native PowerBuilder NonVisualObject directly, rather than being inherited from n_cst_winsrv like the other two Window Services. Note: The Window Resize Service is grouped in the PFCWNSRV.PBL though because it is thought of as a Window Service. This is because the Window begins by re-routing a pfc_resize message to the Window Resize Service instance. In turn, the Window Resize knows which objects are registered with it, so it routes messages to all of them. They also may have their Resize Service turned on, and will therefore resize their controls. This resizing process trickles down nicely. Note: The instance of inv_Resize is automatically destroyed for you in PFC’s Close event via
|
||
|
n_cst_winsrv inv_Base |
Basic Window Service instance | If/when you call of_SetBase (TRUE) to turn on the Basic Window
Service, this instance of the Basic Window NVO is CREATEd so that you may call Basic
Window Services. But because all window services are descendants of n_cst_winsrv (and have n_cst_winsrv functions available to them), use this object only when you require basic window services only. This basically boils down to only when you need to center a window that is not already using the Preference service. Note: The instance of inv_Base
is automatically destroyed for you in PFC’s Close event via
|
||
|
n_cst_winsrv_preference inv_Preference |
Window Preference Service instance | If/when you call of_SetPreference (TRUE) to turn on the Window
Preference Service, this instance of the Window Preference NVO is CREATEd so that you and
the PFC may call Window Preference Services. The Window Preference Service is a big hit with the users. It is very helpful. There are however a few things to be aware about it… Note Note Note Note: The instance of inv_Preference is automatically destroyed for you in PFC’s Close event via
|
||
|
powerobject ipo_PendingUpdates[ ] |
Array of DataWindow controls (and other objects) with Updates Pending | PFC populates this array with all of the DataWindow
controls which have updates pending in the pfc_UpdatesPending event from of_UpdateChecks()
during theCloseQuery
or pfc_Save process. If you have extra objects which have updates
pending, you would extend the This array is then passed to the pfc_Validation, pfc_Update and pfc_PostUpdate events to validate, update and perform post-updates on each control in the array. |
||
|
string is_DBErrorMsg
|
DBError (event) message Stored error message from a database update (from a DataWindow’s DBError event) …which is waiting to be displayed until after the entire transaction has ended (rolled back) |
If an database error occurs during the pfc_Update event,
the error message (from a DBError event for a DataWindow) is held here for display after the pfc_EndTran event properly
ends the transaction (after appropriate ROLLBACK).
PFC calls You should too if you are doing any special update processing within If there is an error during the |
Functions
External Functions
< None >
| Function
|
What is it? Arguments Return Values |
What does it do? When should I call it? |
|
| of_GetCloseStatus
( ) returns boolean |
Status - Closing? Are we in the middle of the closing process at this time? Returns boolean: TRUE = Window is closing FALSE = Window is not closing |
Reports whether or not the window is in the process of
closing. This function simply returns the value of the
|
|
|
of_GetDWType ( datawindow adw_dw ) returns integer |
What kind of DataWindow is this?… Desc of u_dw? + Returns integer: -1 = Error |
Indicates whether a DataWindow is a descendant of u_dw and whether or not it uses the
linkage service
|
|
| 5.0.02 of_GetSaveStatus ( ) returns boolean |
Status - Saving? Is the window in the process of saving data? Returns boolean: TRUE = Window is in the save process |
Reports whether or not the window is in the process of
saving, specifically whether you are in the pfc_Update event. This is because at that
point you are in the middle of a transaction, and you do not want any modal windows to
open which would hold up the transaction in progress. This
function simply returns the value of the
|
|
| of_SetBase
( boolean ab_switch ) returns integer |
Turn on/off Basic Window Services Argument boolean ab_switch: TRUE = Enable service Returns integer: 1 = Success |
Enables or disables n_cst_winsrv, which provides Basic Window Services. This function
simply creates or destroys an instance of n_cst_winsrv. If/when you call of_SetBase (TRUE) to turn on the Basic Window Service, an instance of Note: The instance of inv_Base is automatically destroyed for you in PFC’s Close event via of_SetBase (FALSE)
Note
|
|
| 5.0.02 of_SetDBErrorMsg (string as_msg) returns
integer |
Store the DBError Message to be displayed after
transaction has ended Argument string as_msg : Text of the DB Error message, for example a string containing information such as sqldbcode and sqlerrtext from u_dw’s DBError event Returns integer: 1 = Success |
Stores any DBError message that may have occurred during
the process of saving, specifically when it was in the pfc_Update event. The message is stored
rather than displayed in a modal window because at that point you are in the middle of a
transaction, and you do not want any modal windows to open which would hold up the
transaction in progress. This function simply stores the DBError
message in the
|
|
| of_SetPreference
( boolean ab_switch ) returns integer |
Turn on/off Window Preference Service Argument boolean ab_switch: TRUE = Enable service Returns integer: 1 = Success |
Enables or disables
n_cst_winsrv_preference, which provides Window Preference Services. This function simply creates or destroys an instance of n_cst_winsrv_preference. If/when you call of_SetPreference (TRUE) to turn on the
Window Preference Service, an instance of Note: The instance of inv_Preference is automatically destroyed for you in PFC’s Close event via of_SetPreference (FALSE)
|
|
| of_SetResize
( boolean ab_switch ) returns integer |
Turn on/off Window Resize Services Argument boolean ab_switch: TRUE = Enable service Returns integer: 1 = Success |
Enables or disables
n_cst_resize, which provides Window Resize services. This function simply creates or destroys an instance of n_cst_resize. If/when you call of_SetResize (TRUE) to turn on the window resize
service, an instance of Note: The instance of inv_Resize is automatically destroyed for you in PFC’s Close event via of_SetResize (FALSE) Note The Please refer to
|
|
|
of_UpdateChecks ( ) returns integer |
Check for any validation errors or if there are any
unsaved changes pending Returns integer: 1 = Updates are pending and there are no validation errors |
Triggers the following events
Called in the Note: If the CloseQuery process is in progress, the
|
pfc_w_master’s Key Events ... Note: This section was too big to be included
in this same web page
Tell me a little about pfc_w_master’s PFC descendants…
The following are the extra Functions and Key Events for the PFC
descendants of pfc_w_master. Listed beside them are brief
notes about each one.
| pfc_w_frame |
Functions
Events
| pfc_w_sheet |
Events
is empty, shows
| pfc_w_response |
Events
Other pfc_w_master-Related
Objects
Related Objects to read up on
And what about the changes to pfc_w_master in the PFC 6.0 Release ?
As we mentioned earlier, the changes in thePFC
6.0 Release for pfc_w_master are drastic enough (and not finalized as of this writing) to merit leaving them
out of the detailed discussions of every instance variable, event and function. Trying to
weave the new ones in and talk about all of the changes would be too confusing anyway.
So, as hard as it is now to say with any certainty or any clear knowledge of what will actually be released in the next version, it is important to try ~ as you will probably be reading this after 6.0 is out.
The information contained below is current as of PFC 6.0 Beta 4 - Sept, 1997 to the best of my knowledge. To try to make this as useful and accurate as possible, I have obtained some help from the PFC Development Team themselves. However, they are very busy working on it even as I try to write about it!
So now, let’s take a quick look at what’s projected for the
future 6.0 release of the PFC for pfc_w_master.
PFC 6.0 Release, the Save
Process in pfc_w_master will be dramatically
enhanced…
to specify on which objects and in what order the
-or-
to specify the objects and the order, and to also trigger
of_SetUpdateObjects( powerobject apo_objects[ ] ) function and pfc_SaveObjects
( powerobject apo_objects[ ] ) event will provide
you with a finer-grained control of the save process. They also provide you with a
means to fine-tune your performance, since you would tell the save process exactly which
controls to update, rather than having it search through all controls on the window -
sometimes even drilling thru layers for user objects, tabs and such. With these new
methods, now you can control what gets updated and when. This is because
each of these methods allow you to pass an array of PowerObjects. The controls that you
load into this array are the controls which you would like to be updated. In addition, the
order that you place them into this array, determines which order they will be updated.
- The new
So you would call the
- The new
So you would trigger the new
n_cst_luw. With the introduction of the new LUW service, the LUW transaction is no longer tied
to the window. This will make it easier to process updates from multiple
windows/objects all in one transaction.
So each object is responsible for how to accomplish these tasks, for themselves, as well as any of their "components". Having these set of functions, an object now implements the coined phrase "Self-Updating Object Application Programming Interface (SUO API)". The following PFC objects now include these "self-updating objects" functions:
DataWindow
DataStore
ListView *
TreeView *
Tab
UserObject
Window* Note: These 6.0 ListView and TreeView objects are new, separate PFC LV & TV objects which have the SUO API. This is for upwards compatibility issues. If you use these new objects, you no longer have to override events to have your ListViews and TreeViews update! Another option is to add the SUO API to your existing ListView and TreeView PFE layer objects (see next bullet), and change your pfc_w_master's pfc_save-related scripts.)
For example, if you were to create a Self-Updating Multi-Line Edit control (MLE) by adding the SUO API functions to it; And then you were to place that control on your window; Then, using the default processing, PFC will pick it up and include in the normal
pfc_UpdatePrep event. This new event comes
before the pfc_PreUpdate in the save process, and it will tell all of the update objects to run their of_UpdatePrep( ). I suppose this may be because
there is no SUO APIof_PreUpdate( )equivalent of the window’s
as there is an SUO API
instead, it uses SUO API
which comes before the window’s
PFC 6.0 Release, there
will be a new "Most Recently Used (MRU) Window" Service. 
File menu list. This allows
users to easily go back to windows (or entities) that have previously been opened in
earlier sessions. pfc_w_master has some new events in
order to do things such as:
- Populate the MRU attribute object with the text for the key
(so that the MRU service knows how to store the key)
For example, you may wish to include the window name and any special parameters to pass for retrieval arguments
- Save the current window’s key to be included in the MRU list
(to be done near the opening and/or near the closing of the window)
- Open the particular window properly when the user selects the MRU menu item
PFC 6.0 Release, the
use of Constants makes our code more readable, especially when used to interpret
return codes or to pass our arguments…pfc_w_master public constant which is RETURNed from several events where no action was needed
(because for example there were no objects to take action upon)…
Public:
Constant Integer NO_ACTION = 0
Constant Integer CONTINUE_ACTION = 0
Constant Integer PREVENT_ACTION = 1
PFC
6.0 Release are some exciting new visual user objects that can
be placed on any pfc_w_master window…
Now your application can have the "Explorer" look and feel, or
you can allow the user to easily maximize their window real estate.
You can use multiple splitbars on your window, and they work
in conjunction with the resize service
Handier than its ActiveX counterparts
Best suited for its DataWindow column uses,
but it can be placed on a window as well
Best suited for its DataWindow column uses,
but it can be placed on a window as well,
possibly to select a processing period or something
PFC
6.0 Release take note of a few enhancements to a couple of the pfc_w_master Window-related services…
New way to specify percentages of how to resize/move an object,
so you can have more control over how objects are resized & moved…
For example, if there is a main control that is more important,
that control can stretch faster than the others.For example, before, there was no way to have two objects, side by side, stretch proportionally as the window stretches. You had to stretch one and move the other, but you couldn't stretch them both... With this enhancement, now you will be able to do this. Plus, you can say which one should stretch faster.
Sorry, the following enhancement to the existing
n_cst_WinSrv_SheetManager Window Sheet Manager Service
Option to limit the total number of sheets which can be opened
Option to limit the number of sheets specified by class, title,etc
PFC
6.0 Release, there is a new of_MessageBox( ) function in pfc_w_master. This function simply displays a
PowerScript MessageBox. However its advantage is that you may manipulate the MessageBox
prior to its actual display in any way that you need, to support multi-languages, append
extra info, skip it or log it, etc. It takes all of the MessageBox arguments, plus an
extra argument for the ID of the message…
Please note that this new function is encapsulated into other appropriate objects as well, such as the new
Also, please note that this
Hopefully, this has given you a thorough understanding of the Great, Great GrandDaddy of all PFC
windows, pfc_w_master.
We have covered the 5.0.0# hierarchy and the functionality of your
windows in detail. And we have given you a heads up on what is projected for thePFC 6.0 Release as well. We hope you
have found this information useful, and we hope that you can easily flip back here as a
quick reference in the future.
If you have any questions or feedback on any of this, please feel free to drop me a line at sbuntz@texas.net . I will look forward to hearing from you. In honor of my commitment to quality and my efforts to not spread any misinformation, I will keep any corrections and/or clarifications available online at http://www.pfccheatsheet.com/ . (And if it ends up being elsewhere, there will at least be a pointer to it from there.) Because we live in an age now where things are rapidly changing. And even so, there is no longer one person, or even a small group of people, who really understand and know everything there is now to know.
Sharon Weinstrom Buntz is a CPD Professional who works for NewData Strategies (NDS), a company which provides "high-technology" software, consulting and education services. Sharon is currently a PFC/PowerBuilder mentor at Education Service Center (ESC), Region 20 in San Antonio, Texas.
Her "Cheat Sheet" for PFC/PowerBuilder "Help" is
available for your assistance and convenience at:
http://www.pfccheatsheet.com/
Another PFC resource to keep bookmarked is Boris Gasin’s (of Advent
2000, Inc.) PFC Guide at:
http://www.pfcguide.com/
And don't forget Rik Brooks' Dojo at:
http://www.pics.com/byte/dojo.htm
Please feel free to send Sharon an email at sbuntz@texas.net .
Sharon is forever grateful to the PFC Development Team and the other PFC experts that helped her create, compile and edit this appendix, especially Claudio Quant, Mark Overbey, Brian Grimm, Boris Gasin, Andrew "Brez" Bereznak, Steve Benfield, John Olson, Jon Credit, Bob Fields, Gregory R. George, Ken Howe, Jill Moritz, Judy Cote and Michael Campbell.
And, of course, Sharon would like to thank Rik Brooks for giving her this wonderful opportunity to be a part of this helpful PFC book. Rik is a true pleasure to work with and learn from.
Her heart also goes out to the wonderful people at ESC and NDS who have worked with Sharon, together learning all about the PFC… Linda Sweet, David Terry, Emilio Flores, Mike Uhl, John McCauley, Dan Perez, Al Holden, Ching-Shen Chen, Ching-Shyong Li, Crystal Fox, Jesse Morales, Laura Ellison, Michael Stehling, Robert Okruhlik, Robert Pruski, Roland Gonzales, Thomas Evans, Robbie Hollis, Brenda Hutzler, Gwen Bolden, Joyce McDonald, Lesa Garcia, Paul Rector, Beth Rehn and, again, her wonderful and talented mentor Judy Cote.
Next, Sharon has not forgotten all of her PFC friends on the pfcsig mail list, the pfc-users mail list and the Powersoft newsgroups. The people there so graciously share all of their PFC wisdom and knowledge with other PFCers. And it is a most beautiful experience to be a part of that team spirit that makes anything possible. Hats off to all of them!
And, last but not least… switching now to first person <g>… I would like to personally thank all of my family, my puppies and my husband, John, for all of their love, patience and support... especially while I was submerged <s>.
 Home |
|
|
|
|
Home | Top
