Skip to content

Confirming Data Entry Operations

Sending Confirmations Automatically

DEOs send confirmation messages during important data-entry operations (saves, deletes, clears, exiting). This gives the program a chance to secure confirmation of critical operations from users. Each DEO class has properties that determine what confirmation message is sent for each of these operations.

These messages are usually functions. If the function returns a zero value, the confirmation passed. If it returns a non-zero value, the confirmation failed.

You can use these confirmation functions to pop up a confirmation dialog box asking a particular question (e.g., "Save this Record?"). The popup confirmation is a standard Windows message box that allows the user to respond by pressing Yes or No. After a response, the confirmation panel will disappear, and the function will return a zero (yes) or non-zero (no) value according to the response from the operator.

The DFConfrm.pkg package creates objects to provide such capabilities. It also creates a number of functions that allow you to use these objects. This includes a general-purpose confirmation function (where you pass the question to be asked) and a series of pre-defined confirmation functions.

A DEO needs to know what verification message it should send during a save, delete, clear, and exit. Each DEO has properties that contain the message number to be sent for the appropriate verification. These verification properties are:

If the value of one of these properties is zero, the DEO will delegate and use the message definition in its parent DEO. If the parent's property value is zero (and all of its DEO ancestors are also zero), no message will be sent.

All you need to do is assign the appropriate function messages in DFConfrm.pkg to the appropriate DEO-verify message. The function messages available are listed below.

Save_Confirmation

Prompts: Save this Record?

DEO usage:

Set Verify_Save_Msg to GET_Save_Confirmation

This will most often be used with entry forms and editors that are children of entry forms. Note that when you set the confirmation messages, you need to add the GET_ prefix. Had the function been a procedure, you would have needed the MSG_ prefix.

Delete_Confirmation

Prompts: Delete this Record?

DEO usage:

Set Verify_Delete_Msg to GET_Delete_Confirmation

This will most often be used with entry forms and editors that are children of entry forms.

Line_Save_Confirmation

Prompts: Save this Line?

DEO usage:

Set Verify_Save_Msg to GET_Line_Save_Confirmation

This would be used with grids and editors that are children of grids.

Line_Delete_Confirmation

Prompts: Delete this Line?

DEO usage:

Set Verify_Delete_Msg to GET_Line_Delete_Confirmation

This would be used with grids and editors that are children of grids.

Data_Loss_Confirmation

Prompts: Abandon Changes?

DEO usage:

Set Verify_Data_Loss_Msg to GET_Data_Loss_Confirmation

This message only gets sent when a clear or clear all would result in the loss of data.

Exit_Loss_Confirmation

Prompts: Changes Exist. Exit this window?

DEO usage:

Set verify_exit_msg to GET_Exit_Loss_Confirmation

This message is sent whenever you close (deactivate) a DEO view and there are changes in the view.

No_Confirmation

DEO usage:

Set Verify_operation_Msg to GET_No_Confirmation

Defeats delegation to parent. If a confirmation function is not assigned to a DEO's verify property, the DEO will use the message from its parent DEO. For example, a text_edit DEO will use the same verifications that its parent entry form uses.

Normally, this is good. The no_confirmation message tells the DEO to not use a confirmation prompt and not to use its parent's prompt. This is often needed with the parent-entry-form / child-grid DEO structure. You want a save confirmation for the entry form and no confirmation for the grid. If you don't assign the grid a verify_save_msg, it will use its parent's entry-form message. You must set the grid's verify message to GET_No_Confirmation.

Sending Confirmations Manually

You can send confirmation messages manually. This is useful if you need to send these messages under conditions that your DEO does not normally handle. Below is an example of directly calling a DEO function.

In this example, we want the standard save message ("Save this Record?") to only be sent when a new record is saved. When an edited record is saved, we want the save to proceed without confirmation. We would augment the DEO's request_save procedure to handle this.

// This assumes that this DEO's Verify_Save_Msg is set to no_confirmation.
Procedure Request_Save
    Integer iRec iServer
    Boolean bStat bChanged

    // get current record in server. If 0, it is new.
    Get Server to iServer // the DDO we are using
    Get Current_Record of iServer to iRec
    Get Should_Save to bChanged // is the DDO changed?

    // if a new record and there are changes confirm the save.
    If (iRec = 0 AND bChanged) Begin
        Get Save_Confirmation to bStat // OK=0
        If (bStat) ;
            Procedure_Return      // non-zero=TRUE=not OK, exit
    End

    // Normal save will not perform a confirmation
    Forward Send Request_Save
End_Procedure

The Confirm Function with DEOs

You can send custom confirmation prompts by using the confirm function. It requires that you pass it the prompt to be displayed. The following example shows how you could use the confirm function to make the above example prompt, "Save this NEW record?"

Procedure Request_Save
    Integer iRec iServer
    Boolean bStat bChanged

    Get Server to iServer
    Get Current_Record of iServer to iRec
    Get Should_Save to bChanged

    If (iRec = 0 AND bChanged) Begin
        Get Confirm "Save this NEW record?" to bStat // OK=0
        If (bStat) ;
            Procedure_Return      // non-zero=TRUE=not OK, exit
    End

    Forward Send Request_Save
End_Procedure

You can also use the confirm message to create custom confirmations for a DEO or new confirmations for all DEOs. If we wanted to change an entry form's save prompt to "Save this Order?", we would augment the verify_save procedure in the entry-form object:

Set verify_save_msg to GET_Verify_Save // normal save hook

// Create custom Verify_Save for this ONE object.
Function Verify_Save Returns Integer
    Boolean bResponse

    Get Confirm "Save this Order?" to bResponse
    Function_Return bResponse
    // Here is an alternative method that would combine the above
    // three commands into a single command.
    //
    // Function_Return (Confirm(Self, "Save this Order?"))
End_Function

When we create a verify_save function in a DEO, we are changing the behavior of the one DEO. We could also use confirm to create a new confirm message that all objects could use. We would do this by creating the new function FOR BaseClass (which really means for all classes). We would then assign a DEO's verify message to that new function. The following would allow us to create a "California-style" save message:

Function Verify_Save_California_Style FOR BaseClass Returns Integer
    Boolean bNoWayDude

    Get Confirm "Save this record, Dude?" to bNoWayDude
    Function_Return bNoWayDude
End_Function

Your DEO would use this prompt by placing the following in your DEO:

Set Verify_Save_msg to GET_Verify_Save_California_Style

See Also