|By John Olson||
|January 1, 2000 12:00 AM EST||
Last year, after migrating a client's application from PFC 5.0.02 to 6.5, then applying some enhancements to take advantage of new features, the program began giving the following PFC error message: "For certain functionality the PFC DataStore requires a reference to its parent window. One of these cases has been encountered. To let the DataStore know who its parent window is, call the of_SetParentWindow() function after the DataStore creation."
At first I was disturbed that the PFC developers had coupled the DataStore to a parent object. And worse, not only a parent object, but a window object. This would mean that every DataStore had to be associated with a window. I assumed I'd be forced to use my frame window as a parent for all the "free range" DataStores in my application. After analyzing the PFC code changes, I realized that the DataStore requires a parent window handle only when certain features are used. In each case the handle is necessary for the DataStore to cooperate with the window it's involved in a process with. If you occasionally encounter this message, it's because you're using one of the features introduced in PFC 6.0.
As described in the error message, the solution is to call n_ds.of_SetParentWindow(<window>) for the window that's working with the DataStore. This should be done soon after creating the DataStore.
In this brief column I'll describe each of the n_ds features that require a parent window handle. In many cases the error results from misuse of the DataStore. Therefore I'll provide alternative solutions for each of the causes of the error message.
Cause 1: Update Processes
New functionality added to PFC6 gives DataStores the same capabilities as DataWindows. The most important of these features is the ability to add DataStores to the list of objects to be included in an update process. In PFC6 and 7 there are two different save processes: w_master.pfc_save (window based) and the new Logical Unit of Work Service (cross-object capabilities). In the window-based processing, database errors are handled by storing the error message, aborting the process and returning an error code. The error code tells the overall process to abort, roll back, then display the error message. Because the update process is window based, the error message is stored in the window that controls the process, w_master. When an error occurs in the DataStore update, the parent window handle is needed so that the DataStore can register the error. If it doesn't have a valid window handle, the above error message is displayed.
If there's no main window but you have other objects in the update transaction, you should be using the Logical Unit of Work Service instead of the window pfc_save process.
Cause 2: DataStore Printing
If you execute pfc_print on the DataStore, the user will be prompted with the print dialog. The PFC DLL that provides this dialog needs a handle to a window. If the process doesn't get a valid one, it'll abort.
Instead of calling pfc_print, call pfc_printimmediate. This will bypass the print dialog.
Cause 3: Window Close Process - AcceptText
When the parent window is attempting to close, it executes the "updates pending" process to determine whether changes need to be saved. That process executes pfc_AcceptText events on all objects in the update list. If pfc_AcceptText fails on the DataStore, the DataStore attempts to tell the window to stop its close process. Without a valid parent window handle, it's unable to notify the window.
This occurrence is rare because it requires pfc_AcceptText to fail. It can fail only if:
- The AcceptText() function fails: This happens only if data has been entered into the edit object. DataStores aren't visible, so it isn't possible for the user to enter the data. Therefore the programmer must have used SetText() to put text into the edit. Not only that, but the text must fail validation to cause the error. Though this scenario is unlikely, I recently had the displeasure of debugging code in which a programmer did exactly what I described here.
- You have customized/extended pfc_AcceptText and PowerScript returns a failure code.
Don't call SetText() for a DataStore, and don't add custom code to n_ds.pfc_AcceptText.
Cause 4: Window Close Process - Check Required Columns
When the window is closing and data changes are found, the PFC asks the user if he or she would like to save changes. If the user answers Yes, the update process begins. During the validation portion of the update, of_CheckRequired() is executed. It checks all required columns to make sure they contain values. If the DataStore's of_CheckRequired() finds a required cell that's empty, it attempts to notify the window to stop its close process (this happens only if the window is in the process of closing). Without a valid handle it's unable to notify the window, thereby causing the error.
Don't use required columns in your DataStore's DataWindow object.
When Do You Get an Error Message?
This error message occurs only if the debug service is turned on. It's meant to warn developers that the DataStore needs its ParentWindow registered. If you turn off the debug service, the save process will fail silently. This isn't an issue if the DataStore is updated independently of other objects (not in the same transaction). If it's within a transaction that includes other objects, turning off the debug service is a poor solution and will result in DataStore errors going unnoticed.
- Where Are RIA Technologies Headed in 2008?
- PowerBuilder History - How Did It Evolve?
- Creation and Consumption of Web Services with PowerBuilder
- Cloud People: A Who's Who of Cloud Computing
- DDDW Tips and Tricks
- Cloud Expo 2011 East To Attract 10,000 Delegates and 200 Exhibitors
- Working with SOA & Web Services in PowerBuilder
- Dynamically Creating DataWindow Objects
- OLE - Extending the Capabilities of PowerBuilder
- Cloud Expo, Inc. Announces Cloud Expo 2011 New York Venue