| Parameter | Description |
|---|---|
| hoCallback | Handle to an object in the view that is being closed. This is used to set custom return information to the invoking view. |
Procedure NavigateClose Handle hoCallback
| Call: | Send NavigateClose hoCallback |
NavigateClose is used to close the current view, remove it from the view stack and make the invoking view the top view in a mobile web application (drilldown interface).
It is called when you wish to update the invoking view with a selection made from the view being closed. This is typically needed when you are selecting a record from a list and using this to update the invoking view (e.g., Order Zoom invokes a Customer Select for selection - the classic prompt list). Before the view is closed, it will make sure that any changes are saved or ignored as desired. It will then automatically update the invoking view as appropriate.
NavigateClose is sent to the view that should be closed, which must be the top view in the view stack.
In most cases, the above is all you need to know about NavigateClose - just send the message. The process is described here in more detail.
NavigateClose performs a close by sending NavigateCloseExec (private). If the view being closed has changes, special handling is required. You can choose to present a confirmation dialog (either "Save Changes - Yes/No/Cancel" or "Abandon Changes - Yes/No"), save the changes without confirmation or abandon the changes without confirmation. The different options for closing a changed view are controlled by the peChangedViewExitAction, Verify_SaveClearCancel_msg, Verify_Data_Loss_msg properties.
If there are no changes in the view or if there is need for a close confirmation, NavigateCloseExec will be called directly.
If changes exist and a confirmation is required, a client confirmation dialog will be presented, requiring an additional client/server round trip. If the close is confirmed, NavigateCloseExec is called indirectly by the client in the next request/response cycle.
If the close is not confirmed, the close process is halted. NavigateCloseExec may require a save. If a save is required and this save fails, the close will be halted.
Assuming the close process continues, the closing view's tWebNavigateData will be obtained. This is the tWebNavigateData data that was passed into the view when it was invoked and accessed with GetNavigateData. The event OnGetNavigateBackData will be sent to the hoCallback object, passing this NavigateData. The hoCallback object is an object in the view that is being closed. This allows the developer to make any changes in the NavigateData data.
Next, the invoking view will update itself based on contents of tWebNavigateData data. When the Navigate-From type is nfFromChild or nfFromMain, the view will be updated with the current or selected record from the view being closed.
Finally, if the back navigate succeeded without any refind errors, the event OnNavigateBack is sent to the invoking object that initiated the original forward navigate. This does nothing but can be augmented to handle custom updates. This is useful when this is returning information from a non-related view (i.e., the navigate-from type was nfUndefined).
A back navigation can fail if DDO records cannot be refound. This can happen when data is changed in a multi-user environment or possibly by a programming error. When this happens, OnNavigateBackRefindError is sent in place of OnNavigateBack. See OnRefindRecordError for more on this.
If you want to close the current web view and are not using a callback object, you can simply call NavigateClose and pass Self:
Send NavigateClose SelfSee Also
NavigateBegin | NavigateCancel | NavigateCancelTo | NavigateCloseTo | NavigateForward | NavigateForwardCustom | NamedValueAdd | NamedValueGet