SaveSelectedRow - cWebGrid

Performs a DD save row operation

Type: Function

Return Data Type: Integer

Parameters: None

Return Value

Returns True if the save was successful.

Function SaveSelectedRow Returns Integer

Call: Get SaveSelectedRow to IntegerVariable


SaveSelectedRow performs a save row operation by sending Request_Save to the object's DataDictionary object (DDO) Server. If the DDO has nothing to save, it just returns. An optional save verification confirmation message may be presented. This message is only sent if the there is something to save and the data entry object's (DEO's) Verify_Save_msg is set. This operation is performed using the RequestSaveExec message as described below. It is usually initiated by the Request_Save message, which calls SaveSelectedRow.

Note that this performs a DD Request_Save operation. Saves propagate up the DDO structure.

RequestSaveExec - Request messages and user verifications with web objects

When the browser client selects a save, delete, clear or clear-all the message Request_Save, Request_Delete, Request_Clear or Request_Clear_All is sent to the server. These do a traditional DataFlex style request operation which is validation, verification and then the actual DD operation (Request_Save, Request_Delete, Clear, Clear_All). A verification is required based on the contents of Verify_Save_msg, Verify_Delete_msg and Verify_Data_Loss_msg. If a verification is required, the client needs to get involved to perform the user verification. This means that the operation requires an additional round trip. If the verification is accepted by the user, a message is sent to the server which handles part two of the request. Those part two messages are RequestSaveExec, RequestDeleteExec, RequestClearExec and RequestClearAllExec. These are the messages that attempt to actually perform the requested DD operation. You can think of these as "pre" and "post" messages.

If the verify messages are 0, which means that a user confirmation is not needed, the "pre" message (e.g. SaveSelectedRow) will directly send the "post" message (e.g. RequestSaveExec) without requiring an additional trip to the client.

Here is a rough outline of what happens with a SaveSelectedRow.

    If no changes return
    Validate All
    If not Valid return with errors
    If Verify_Save_msg, tell client to present the verification and return *
    Else Send RequestSaveExec

    Validate All **
    If not Valid return
    Send Request_Save to DDO
    If no Error
        Clear the record and appropriate DEOs

* If the user confirms the operation, the client will make another server request which will indirectly send RequestSaveExec

** The validate All will actually be a duplicate of the prior validation, which means it should validate. It is here as a safeguard. If it does not validate something is wrong and the operation is stopped.

If you need to make a save, delete, clear, clear_all request manually (e.g., within a cWebButton) you should use Request_Save, Request_Delete, Request_Clear and Request_Clear_All and not these "exec" messages.

If you are augmenting these requests, you need to be careful, as they occur in two steps and it is possible that the second step (the exec) may not get called at all. Notice that the "pre" message (e.g., Request_Save / SaveSelectedRow) may have actually performed the entire operation (if there is no verify message) or may have merely launched the operation which might be completed during the next server "post" request (e.g. RequestSaveExec).