ABL uses named frames as client endpoints for DDE conversations. A DDE frame, in effect, owns the client end of a conversation. You specify the DDE frame for a conversation when you open it with the DDE INITIATE statement.
A DDE frame can be visible or hidden during application execution. A hidden DDE frame effectively insulates the user from the conversation, preventing any unintended user intervention. However, the frame must be realized before you can open a conversation with it. That is, you must make it visible before hiding it (set the frame VISIBLE attribute = TRUE; then the HIDDEN attribute = TRUE).
A DDE frame can be a client endpoint for more than one DDE conversation, and you can use multiple DDE frames to open multiple conversations with the same application and topic. Your decision to use one or more DDE frames depends entirely on how you decide to allocate frames for your application and distribute DDE conversations among them. Otherwise, it makes no difference whether you use one or many DDE frames for conversation endpoints.
Each DDE frame provides a set of frame attributes that maintain the status of conversations owned by the frame. The following table lists these DDE frame attributes.
Each time a conversational exchange occurs—that is, each time a DDE statement executes or ABL posts a
DDE-NOTIFY event—ABL updates the DDE attributes of the frame that owns the conversation. These attributes are especially useful for determining the exact nature of a DDE run-time error (
DDE-ERROR) and identifying the data item that triggered a
DDE-NOTIFY event (
DDE-NAME,
DDE-TOPIC, and
DDE-ITEM). (For more information on
DDE-NOTIFY events, see
Exchangingdata in conversations.)
