Container Technology in Visual DataFlex

Recently, I worked with a co-developer who coded a similar procedure such as this:

Procedure Item_Change integer iFromItem integer iToItem returns integer

Integer iRetVal
Forward Get Msg_Item_Change iFromItem iToItem to iRetVal

If (Current_Col(Self) = 2) Begin
Send Request_Save of oProdLine_DD
End
Procedure_Return iRetVal
End_Procedure

What came of the conversation we had was that the "Send Request_Save" actually (and unintentionally) avoided the container technology of Visual DataFlex so that validation, the confirm message, and the ability to augment these functions in the container were completely misdirected!

Here's what happens when a Request_Save is sent by normal means (i.e. clicking the save button, using the save key, changing a row in a dbgrid, etc):

• The container runs request_validate of the server ddo and validates the datadictionary class rules upon the data. Upon failing, the save is aborted, a message about the error is sent to the user, and the focus attempts to go directly to the window or cell that doesn't pass validation. Upon success, the next step occurs.
• The container then runs the function named in the verify_save_msg property handle. "Would you like to save?", or a custom message if you have programmed it. Upon a NO answer, the save is aborted and the focus returns to the object or cell in the focus tree. Upon a YES answer, the save cascade of messages continues.
• The container then asks the DDO (server) to save. Upon any error, all changes are rolled back and the focus returns to the object/cell in the focus tree.
• Then, the container (if it's not a data aware grid or list) clears the buffer and the ddo record attached to it.
• Then, the container (if it's not a data aware grid or list) sends the message "beginning_of_panel" (augmentable) which determines the first focusable object on the form/view and gives the focus to it.
• DONE

So, as many are aware, when you take control of the save mechanism to do it manually, you should do the following steps:

1. Request the ddo validation to a boolean: Get Request_Validate of oProdLine_DD to bCancel.
2. Ask or confirm the save: Get Confirm "Would you like to save?" to bCancel
3. Send the save command: Send Request_Save of oProdLine_DD
4. Upon success, clear the record: If (Not(Err)) Send Clear of oProdLine_DD
5. Move the focus: Send Beginning_Of_Panel

So, in summary, the container technology has 5 main steps to it (actually six!). Prior to any of the five actions, it asks the server DDO if there are any changes to save! If there are no changes to save, then none of the above five steps ever execute.

Many are familiar with the Save cascade of messages from creating, backout, update, etc. but the container cascade of messages/methods is also important to realize prior to the save cascade ever occuring.

Posted by:

Peter A Donovan

http://www.applausesoftware.com/