Skip to content

View Navigation Properties

Overview

A view behaves based on its view type and by how and where it was navigated from.

From any view, you can navigate from:

  1. Main
    The main view's counterpart (Select to Zoom, Zoom to Select) – this is called from-main. An example of this would be navigating from a customer Select view to a customer Zoom view.

  2. Parent
    You can navigate to a constrainable child view (Select or Zoom) from a parent view. An example of this would be a customer view (Zoom or Select) that navigates to a list of orders constrained to that customer. The new view’s main-DDO will be automatically related to the invoking view’s main table. This is called from-parent.

  3. Child
    Any view can navigate from a child view to a related parent view (Select or Zoom). An example of this would be the order Zoom view navigating to the parent customer Select. This type of navigation is used most often to select a parent during data entry. This is called from-child.

  4. Undefined
    A view can navigate to any other view with no implied relationship. An example of this would be a Zoom view that navigates to an unrelated Select view like a validation table. Another example is adding the first view to the view stack, where it is not coming from anything or coming from a Dashboard, which has no relationship to the view. This is called from-undefined.

Note that one can describe navigation in terms of where you are navigating to or where you are navigating from. We will mostly be using the “from” point of view. When a view is being shown and added to the view stack, we want to know where it came from.

It is the developer’s responsibility to send the message that instigates a forward navigation from one view to another. This is done by sending a message to the new view to be invoked, passing the handle of the object that requested the navigation. In a forward navigation, the most important piece of information is the navigation from-type. The framework classes will determine the from-type for you. It does this by looking at the view being invoked and comparing it to the invoking view and object. The types from-main, from-parent, and from-child all expect that there will be a sensible relationship between the tables/DDs in the two views, and it uses this information to determine the from-type and to perform a proper navigation based on this type.

You never want to be able to navigate forward to a view that is already in the view stack. This solves a circularity issue, which avoids both logical and technical problems. Rules to avoid navigation circularity are enforced and are described later.

See Also