Typically PFC service is enabled and configured from the constructor event of the service requestor object. If you examine the sample application (w_linkagefilter) that is exactly where the linkage service was configured:
| //dw_cust (master) constructor |
| of_SetLinkage(true) |
| //dw_sales (detail1) constructor |
| of_SetLinkage(true) inv_linkage.of_SetMaster(dw_cust) inv_linkage.of_Register("cust_id", "cust_id") inv_linkage.of_SetStyle(inv_linkage.FILTER) |
| //dw_lineitem (detail2) constructor |
| of_SetLinkage(true) inv_linkage.of_SetMaster(dw_sales) inv_linkage.of_Register("sales_id", "sales_id") inv_linkage.of_SetStyle(inv_linkage.FILTER) |
However, the linkage service interacts with multiple datawindow controls. The constructor event sequence of these controls depends on the order in which they were placed on the window. This sequence is not predictable and may change after another control is added to the window or a user object. If the dw_sales constructor event fires first, the of_SetMaster(dw_cust) function will fail because the dw_cust has not yet been registered with the linkage service. Because the linked datawindows have to be registered in a specific sequence the linkage service should not be configured from the u_dw constructor event.
A better approach is to configure the linkage service from the parent window or a user object.
| //w_linkagefilter pfc_preopen |
| dw_cust.of_SetLinkage(true) dw_sales.of_SetLinkage(true) dw_lineitem.of_SetLinkage(true) dw_sales.inv_linkage.of_SetMaster(dw_cust) dw_sales.inv_linkage.of_Register("cust_id", "cust_id") dw_sales.inv_linkage.of_SetStyle(n_cst_dwsrv_linkage.FILTER) dw_lineitem.inv_linkage.of_SetMaster(dw_sales) dw_lineitem.inv_linkage.of_Register("sales_id", "sales_id") dw_lineitem.inv_linkage.of_SetStyle(n_cst_dwsrv_linkage.FILTER) |
Oooo... Another tip. You may have noticed that the constants were referenced through the powerbuilder global varible n_cst_dwsrv_linkage. Even though the global variable does not point to a valid object instance in memory, that is perfectly legal becuase the constants are resolved at compile time. This approach may be appropriate when the instance variable is path is longer - dw_lineitem.inv_linkage.FILTER
In other words dw_lineitem.inv_linkage.FILTER is equivalent to the n_cst_dwsrv_linkage.FILTER, which is a whooping 3 charachters shorter <g>.
Contributed by Sharon Buntz
This is a drawback of using the Retrieval style of the Linkage service. And it is a sticky problem to try to code around, but it can be done. The problem is that there is no RowFocusChanging event in order to trap that the row's focus is changing to test if you should ask the user if they would like to save their changes.
One option is to simply switch to using the Filter style of the Linkage service. This is a viable solution for cases when you are not forced into using the Retrieval style because of very large quantities of data that would need to be retrieved.
On the bright side, please note that in PowerBuilder 6.0, there will be a RowFocusChanging event. And also, in PFC 6.0, this problem will be fixed as well, using the new RowFocusChanging event.
Contributed by Sharon Buntz
When using the retrieval style of the Linkage service, there is no need to code anything in your Detail DataWindow's pfc_retrieve event. There is code in the PFC to automatically do this for you. It is keyed off of when the Master's RowFocusChanged event occurs. And it assumes that when the initial RowFocusChanged event occurs, the initial retrieve has already occurred.
But if the initial Master RowFocusChanged event (that normally first occurs immediately following the Master's retrieve) happens too soon, then the initial Detail retrieve will slip past. Therefore, do not perform any Modify( )'s that may cause a RowFocusChanged event to execute too early. One example of such a case is if you change a column's .protect attribute dynamically (such as for security reasons). For this scenario, using .tabsequence rather than .protect will be okay since the .tabsequence does not have the side effect of causing the rowfocuschanged event to fire.
Also double-check your column names specified in your inv_linkage.of_SetArguments( ). The column names must match exactly how they are seen when you select menuoption "Rows/Column Specifications" in your DataWindow painter for that particular Master/Detail DataWindow object. Also, try checking the return code from your of_SetArguments( ) function [returns 1 if the function succeeds and -1 if an error occurs].
Contributed by Sharon Buntz
For the Retrieval style of the Linkage service to properly retrieve, you must have the proper retrieval arguments set up in your Detail's DataWindow object, in its Datasource. The PFC code will automatically pass the retrieval arguments for you, but if the DataWindow object is not expecting any retrieval arguments, they will be ignored, and so the retrieve will not work as expected.
Contributed by Sharon Buntz
When using the Retrieval style of the Linkage service, there is no need to code anything in your Detail DataWindow's pfc_retrieve event. However, with the Filter style, you do need to code your retrieve in the Detail DataWindow's pfc_retrieve event. So make sure that you have coded your retrieve in there.
Also double-check your column names specified in your inv_linkage.of_SetArguments( ). The column names must match exactly how they are seen when you select menuoption "Rows/Column Specifications" in your DataWindow painter for that particular Master/Detail DataWindow object. Also, try checking the return code from your of_SetArguments( ) function [returns 1 if the function succeeds and -1 if an error occurs].
Contributed by Sharon Buntz
Be aware that when your Detail rows are filtered, Required Columns may slip by the validation checks. To remedy this, please see the at this site.
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.