DeleteSelectedRow - cWebList

Performs a DD delete row operation

Type: Function

Return Data Type: Integer

Parameters: None

Return Value

Returns True if the delete was successful.

Function DeleteSelectedRow Returns Integer

Call: Get DeleteSelectedRow to IntegerVariable


DeleteSelectedRow performs a delete operation by sending Request_Delete to the object's DataDictionary object (DDO) Server. If the DDO has no current record (nothing to delete), it just returns. An optional delete verification confirmation message may be presented. This message is only sent if the there is a current record and the data entry object's (DEO's) Verify_Delete_msg is set. This operation is performed using the RequestDeleteExec message as described below. It is usually initiated by the Request_Delete message, which calls DeleteSelectedRow.

Note that this performs a DD Request_Delete operation. Deletes delete the record, deletes child records (if allowed) and updates parent records.

If the delete is successful the row will be deleted and the grid updated.

RequestDeleteExec - 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. Request_Delete / DeleteSelectedRow) will directly send the "post" message (e.g. RequestDeleteExec) without requiring an additional trip to the client.

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

If no current record return
If Verify_Delete_msg, tell client to present the verification and return *
Else Send RequestDeleteExec

Send Request_Delete to DDO
If no error
Find the next record in the grid and update the Grid

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

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_Delete / DeleteSaveSelectedRow) 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. RequestDeleteExec).