Skip to content

Using the Confirm Package

It is very easy to hook DEOs into confirmation messages. Your program must first include the DfConfrm object package (which is included, by default, in DFAllent.pkg). Each DEO should contain code that looks like the following:

Set Verify_Save_Msg       to GET_Save_Confirmation
Set Verify_Delete_Msg     to GET_Delete_Confirmation
Set Verify_Data_Loss_Msg  to GET_Data_loss_Confirmation
Set Verify_Exit_Msg       to GET_Exit_loss_Confirmation

By default, the dbView class defines the above confirmations as their default. The dbGrid class changes the save confirmation (to disable the confirmation - get_no_confirmation) and the delete confirmation (to ask for a line delete confirmation - get_line_delete_confirmation). You would only need to change a class or object if you needed to change these defaults.

You are encouraged to create your own confirm package. This could contain different or additional prompts. You might also want to create your own custom DEO subclasses that contain the prompts that you always want to appear in your programs.

The following example would create a custom dbView subclass that always verifies saves, deletes, and clears, but does not verify exits:

Class dbView_xyz is a dbView
    Procedure construct_object
        Forward send construct_object
        Set Verify_Save_Msg       to GET_Save_Confirmation
        Set Verify_Delete_Msg     to GET_Delete_Confirmation
        Set Verify_Data_Loss_Msg  to GET_Data_loss_Confirmation
        Set Verify_Exit_Msg       to GET_No_Confirmation
    End_Procedure
End_Class

When your confirm logic is placed in subclasses that all objects use, your programs will no longer need to set the properties in each DEO, and you will be assured that all of your DEOs will behave consistently. This will also make it very easy to add more sophisticated verification capabilities to all of your objects. It shouldn't be too hard to create classes that allow confirmations to be turned on and off at the user level.

See Also