The cWebView Class
Summary
Understanding Navigation
Most of the web framework extensions were made in the cWebView class. A cWebView object can now operate in two modes: Desktop style or drilldown style. The style must be set at design time. The cWebView property peWebViewStyle determines if the view is desktop style (wvsDesktop) or drilldown (wvsDrilldown).
Normally, you would want all views in an application to be the same. When a cWebView is created, it sets its peWebViewStyle to the value of the parent cWebApp object’s peApplicationStyle. This means that the main cWebApp object determines the style of its views. It is possible to mix view styles by explicitly setting peWebViewStyle in your view’s subclass or object.
The view’s application style (peWebViewStyle) determines how a view and its DEOs operate. For example, the style determines how DEOs are dynamically enabled/disabled, whether prompt lists should be automatically used, how Autofind should work, and if DDO structures should have automatic relates-to constraints applied.
The combination of a mobile/touch application using the drilldown style may require other changes that a developer will want to consider. This will impact the standard Save, Delete, Clear, and Close operations as follows:
Save Operations
If a user presses a save option (button or menu), you may wish to suppress any confirmation dialog. This is in keeping with the philosophy that a mobile operator knows what they are doing and they want a smooth flow in their application. You would disable the save verification by setting Verify_Save_msg to 0.
After a successful save, you may wish to automatically proceed to the next step. If the save occurs within a Zoom that was invoked by a Select (list), you may wish to return to the list. Alternatively, you may wish to navigate forward to some other view. The OnViewSaved event is called after a successful save. You can use this to perform any post-save behavior you wish, such as navigating back to the invoking view (NavigateClose).
Delete Operations
It is always difficult to predict how a developer will handle deletes. You may wish to delete without confirmation, delete with confirmation, or not allow deletes at all. The delete confirmation dialog can be suppressed by setting Verify_Delete_Msg to 0. A delete can be disallowed by simply not providing a delete option.
After a successful delete, you may wish to automatically proceed to the next step. If the delete occurs within a Zoom that was invoked by a Select (list), you may wish to return to the list. Alternatively, you may wish to navigate forward to some other view. The OnViewDeleted event is called after a successful delete. You can use this to perform any post-delete behavior you wish, such as navigating back to the invoking view.
Clear Operations
The traditional DataFlex Clear and Clear All options may not make as much sense in a drilldown system. The minimalist approach to this would be to not allow this at all in Zoom views. Instead, you may wish to add a “New” button to your Select view that, upon selection, navigates forward to your Zoom, which is cleared and ready for new data entry.
If you do choose to place a “New” option within your Zoom view, you can create a button that sends Request_Clear and choose to suppress data loss messages by setting Verify_Data_Loss to 0. After a successful clear, the OnViewCleared event is called. You might use this to change the appearance of your view (e.g., change a caption).
You may wish to have an option that will undo any unsaved changes you might have made. This is really more of a refresh operation. The cWebView RefreshRecord message can be used for this purpose.
Changed View Navigation
The changed view navigate back behavior has already been discussed. It uses the peChangedViewExitAction to determine if a changed view should display a “Save – yes, no, cancel” dialog, a “data-loss” dialog, auto save, or just close. The latter two save options actually make it possible to not have to provide a save button in your view at all.
Query-Based Applications
It is expected that touch/mobile applications will be query-based, where data entry will be the last thing you do and possibly will not be allowed at all. This is a different model than the desktop style, where data entry is usually allowed. In the desktop style, even when changes are not allowed, many DEOs within a view must be enabled so you can perform finds for query purposes.
With the drilldown model, a read-only view should disable all DEOs in the view. With drilldown views, it may make sense to navigate to a Zoom view displaying a record that is in read-only mode. If editing is allowed, a button can be provided to change the view’s mode to editable. When this happens, the DEOs must change their enabled states based on whether a particular DEO is editable. The views and DEOs know how to do this. You can change edit modes and perform this DEO update process by creating a button that sends the cWebView's ChangeEditMode message.
Previous Topic: Summary
Next Topic: Understanding Navigation