Parameter | Description |
---|---|
NavigateData | This is the tWebNavigateData variable that pretty much defines the context for navigation. This data could now be accessed with GetNavigateData, but it is passed here as a convenience. Normally, you will just use this data to make other decisions. If you need to change any of the struct's members, you will need to use SetNavigateData to update the value yourself. This is considered an advanced technique. |
hoInvokingView | This is a handle to the view that invoked this view, which will be the view one level down on the view stack. The current view is the top view and the invoking view is the next view in the stack. You may use this to obtain additional information about the invoking view. It is possible for hoInvokingView to be 0, which means that this view is the only view on the stack. The invoking view is always synchronized. This means you can access any web property data from this view. |
hoInvokingObject | This is a handle to the web object that invoked this view. This is the object passed to NavigateForward and is the object which has already received the event OnGetNavigateForwardData. You may use this to obtain additional information about this invoking object. It is possible for hoInvokingObject to be 0, which means that you don't know where it came from. It is also possible that hoInvokingObject may not be a child of hoInvokingView. |
Procedure OnNavigateForward tWebNavigateData NavigateData Handle hoInvokingView Handle hoInvokingObject
The OnNavigateForward event is sent to the object that is being shown at the end of the NavigateForward process in a mobile web application (drilldown interface).
This is the event you can use to fully customize a view based on the context of how it is invoked.
You will use OnNavigateForward for two main purposes:
1. Change captions and labels to provide more contextual information to the user.
2. Hide and Show buttons based on how this view is being used.
Often you will want to make changes based on the eNavigateType member of NavigateData variable. A skeleton of what your code might look like in a view is:
Procedure OnNavigateForward tWebNavigateData NavigateData Integer hoInvokingView Integer hoInvokingObject // turns all buttons on WebSet pbRender of oButton_1 to True WebSet pbRender of oButton_n to True // now for the different navigate types, turn off unnecessary buttons Case Begin Case (NavigateData.eNavigateType = nfFromMain) // a main file lookup Case Break Case (NavigateData.eNavigateType = nfFromChild) // a parent lookup Case Break Case (NavigateData.eNavigateType = nfFromParent) // A constrained parent query Case Break Case Else // unknown, probably the start of query. You might need to // use NamedValues to further refine this operation Case End End_Procedure
This is often more than you will need. Rather than trying to create a single multi-purpose view, you could easily create multiple single-purpose views and avoid this conditional code. The choice is yours. Once you get used to dealing with all of the different Navigate-From types, you should find that you can do just about anything you want in a single multi-context view.
OnNavigateForward can use the NavigateData data in the following ways:
1. eNavigateType - this tells you where you view came from and is the single most important piece of information passed to the view. This is the most likely scenarios:
a. nfFromMain - If your new view is a Zoom, this is a Select list to Zoom for the same table (e.g., customer Select to customer Zoom).
b. nfFromChild - If your new view is a Select, this is probably a parent lookup from a Zoom (e.g., an Order Zoom view to a customer lookup List).
c. nfFromParent - If your new view is a Select, this is a constrained parent to child drilldown. The invoking object might either be from a Select or a Zoom parent (e.g., a customer list to a list of orders for that customer or a customer Zoom with a button that lists orders for that customer).
d. nfUndefined - If your view is a Select, this is probably the start of a query. This might have been started from the dashboard or started from a menu. If the view is a Zoom, this might have been selected from the dashboard. Sometimes you need to pass a bit of extra information for from-undefined (after all, it is undefined). NavigateData.NamedValues can be used for that. This may be the start of a drilldown query or this may be used for some kind of custom query. You may have set tWebNavigateData.NamedValues to provide more information about this.
2. iTable - When used with nfFromParent, this lets you know which parent table is being used for the relates-to constraint. When used with from main or from child, this tells you what your main table is (which you probably already know).
3. bNewRecord - When this is True, it indicates that your view, probably a Zoom, is adding a new record. You could also check the HasRecord property of your view's Main_DD to see if you are adding a new record.
4. bReadOnly - When this is True, it indicates that this view is a read only view. You could also test this with the IsViewReadOnly function call. If a view is read-only, all of the data entry obects (DEOs) will be disabled. You still may need to disable other controls, such as buttons, yourself. If you wish to change a read only view to be editable, you can send the ChangeEditMode message.
You are advised to look at the sample to see all of the ways OnNavigateForward can be used.