Refresh - cWebList

Parameter

Description

eMode

The mode type of DDO operation which generated this refresh message. It may be one of the following: Constant Meaning Mode_Clear Used only for DEOs attached to the DDO that was the "origin" of a clear operation, (i.e., the DDO received the original Clear message). All other DDOs send their DEOs the refresh message passing mode_find_or_clear_set. Mode_Find_or_Clear_Set Used for DEOs attached to DDOs which have found and/or cleared records. Mode_Clear_All Used for DEOs attached to any DDO that participated in a clear_all operation. Mode_Delete Used for DEOs attached to any DDO that performed a successful deletion. DDOs that were merely updated as the result of a deletion use Mode_Find_or_Clear_Set. Mode_Save Used for DEOs attached to any DDO involved in a successful save operation.

Procedure Refresh Integer eMode

When a DDO operation, such as a save, delete, clear or find, occurs, the data entry objects (DEOs) connected to DataDictionary object (DDO) structure are sent the Refresh message. This is used to by the DEOs to synchronize themselves with the current record. Each DEO will display and clear data as needed.

This is a good message for augmentation. All changes in DDO activity are filtered through this message. When augmenting, you will almost always want to forward send the message.

When Refresh is called, the DDO structure and the table's file buffers are all up to date. You can use this information to customize the Refresh. If needed, you can use eMode to determine what type of DDO operation occurred. Because DDO operations are complex, a single operation, such as a find, might cause records within a DDO structure to be cleared, found or left alone. If you need to know the status of a particular table within a Refresh, you can use the DDRefreshTableStatus to determine a table's role in the DD event.

In addition to DDO and table buffers, internal change states are maintained during a Refresh and these internal states are easily changed. As a general rule, you do not want to change these buffers or find additional records within Refresh, as this might cause the entire Refresh event (i.e., where a DDO structure sends Refresh to many DEOs) to become unstable.

Within Refresh, you cannot send any DDO request messages to any DDO within your application. This includes, but is not limited to Request_Save, Request_Delete, Clear, Clear_All, Request_Find, Find, FindByRowId and Request_Read. If you are very careful, you can send Locate_Next and ReadByRowId -- this technique is used fill records in data aware grids. You can also directly find records from tables that are not part of the DDO structure.

The Refresh event is complicated and plays a central part in keeping DDOs and their web DEOs synchronized. Be careful if you augment or replace this event.

Important: In web applications, you will usually want to disable any refresh logic when your application is being initialized or when it is being synchronized to a request. In our code we always check the cWebApp AppSynching function and skip the refresh if it returns True. If you are augmenting this event and you plan on changing web properties (which is a mean reason you'd augment this), you will want to perform this same test.

Procedure Refresh Integer eMode
    Boolean bAppSynching
        
    Get AppSynching to bAppSynching

    Forward Send Refresh eMode

    If (bAppSynching) Begin
        Procedure_Return
    End
   
     // add your augmentation here

End_Procedure