AddDDOStructure - cWebView
Informs the view that additional DDO structures exist that are not connected to the main DDO Structure
Type: Procedure
Parameters
| Parameter | Type | Description |
|---|---|---|
| hoMain_DD | Handle | Handle of the main DDO of the DDO structure to be added |
Syntax
Procedure AddDDOStructure Handle hoMain_DD
Call Example
Send AddDDOStructure hoMain_DD
Description
The DataFlex framework specifies that each view contains a structure of connected DataDictionary objects (DDOs) and that the main DDO in this structure is specified with the Main_DD property. This is how almost all views in DataFlex are constructed. In Windows development, some developers have stretched this rule by adding additional DDOs or additional DDO structures in the view that are not connected to the Main_DD structure. While this technique is not part of the framework rules, if used carefully, it has been found to be useful. This is also possible with web applications, but it requires the use of AddDDOStructure.
This web framework needs to store DDO information on the client. It uses a view's Main_DD to obtain information about your DDO structure and it does this automatically. Just like in Windows, you can create additional DDOs or DDO structures that are not part of the Main_DD structure. Unlike in Windows, you must notify the view that you are doing this by sending AddDDOStructure, passing the handle of the extra DDO. If this extra DDO is connected to other DDOs, all of those DDOs will be added to the view's list of DDOs.
Below is an example of adding an extra customer DDO to a view.
Object oDemoMultiDDOStructure is a cWebView
// DDO Structure 1: this will be the view's main DDO structure so it does not need to be registered
Object oCustomer_DD is a Customer_DataDictionary
End_Object
Set Main_DD to oCustomer_DD
// DDO Structure 2: We need to register this so it will be synchronized at the client
Object oInactiveCustomer_DD is a Customer_DataDictionary
Procedure OnConstrain
Constrain Customer.Status eq "N"
End_Procedure
End_Object
Send AddDDOStructure oInactiveCustomer_DD
In this example, two extra DDO structures are added to a view (Vendor and Invt with yet another Vendor DD). This shows that AddDDOStructure must be used for each extra DDO structure. It also shows that you only need to register one DDO within any extra connected DDO structure.
Object oDemoMultiDDOStructure is a cWebView
// DDO Structure 1: this will be the view's main DDO structure
Object oCustomer_DD is a Customer_DataDictionary
End_Object
Set Main_DD to oCustomer_DD
// DDO Structure 2: We need to register this so it will be synchronized at the client
Object oVendor_DD is a Vendor_DataDictionary
End_Object
Send AddDDOStructure oVendor_DD
// DDO Structure 3: We need to register this so it will be synchronized at the client
Object oVendorTwo_DD is a Vendor_DataDictionary
End_Object
Object oInvt_DD is a Invt_DataDictionary
Set DDO_Server to oVendorTwo_DD
End_Object
Send AddDDOStructure oInvt_DD // add both DDOs because they are connected
This technique needs to be used with caution, as it is considered to be straying from one of the basic framework rules, which is that a view consists of a single structure of connected DDOs that are connected to data entry objects (DEOs) within the view. The more one strays from this, the stranger things get. Our advice would be to see if your needs can be met using a single connected DDO structure and only use this technique if there is no better choice (considering that a better choice may be "don't do this at all").