Views

Views are the part of the application responsible for actually allowing user interaction with a document. The following image shows a view contained within an MDI child frame;

The nature of a view depends entirely on it's function. All views, whether in a toolbar or, used as a means to manuipulate a primary document type share common elements. These common elements are present in the screenshot above.

The function of the scrollbars is self explanatory, but there are a couple of things worth mention.

We aim to ensure that the maximum amount of desktop area is available for use by a user's views. To this end we rarely disable a scrollbar, leaving it inactive and grey. If a scrollbar is not valid, then it is removed from the display entirely. Such a requirement seems trivial from the user perspective, but from a programming perspective it is much less less so. The problem stems from the general window layout process. When sizing windows, it is important to calculate the presence or absence of such scrollbars, before they are presented. The reality is that the scrollbars impact on the size of the window, and as a consequence, and without care, infinite recursion is possible.

We manage this problem at source, such that it never has an impact on the implementation of a view, when programming. This capability seems trivial, but it's an almost impossible capability to add as an afterthought.

Although a need for their use is unlikely, the scrollbars support a left mouse click popup menu. This menu is of benefit in the very rare circumstance that one wishes to work in a window so small, that the scrollbar itself has insufficient size to allow the other clickable parts to be usable.

Some other user interfaces offer a split pane capability, with a draggable token near the end of a scrollbar. Clearly such a capability directly contradicts our policy to hide scrollbars which are not in use. Instead we extend another capability to partially satisfy this need. All views have the capability to be multiple. In practice this is manifest in what we describe as tabs, seen below;

A user is able to slide the tabs using the blue arrow buttons on the left, where tabs are partially visible. In addition the small blue slider on the right allows the relative size of the scrollbar and the visible tabs to be controlled. The tabs can be horizontally or vertically aligned with the view. This is typically done to optimise display real estate, in toolbars, but the standard view only allows tabs horizontally at the bottom. Flexibly, the tabs can be closable, with a small red close button, or plain and without the button. If the number of views increases above one, or decreases below two, then the tab control appears and disappears respectively.

These tabs have the capacity to work in a variety of ways, but the two main models are, duplicate and alternate.

In duplicate mode, a new but similar view may be created on one document. The new view has it's own mode settings, and scroll position. Using the duplicate mode one can work at two locations in the same file, and switch between those locations with ease, using the tabs.

Alternate mode, allows more than one type of view on a document. In this mode it is possible to have a file/document that contains data. One view on that document might be raw data, like perhaps a numeric table, another view on the document might be an actual graph or pie chart which is derived from the same data.

In general, alternation is a superset of duplication. A view will support one or other of these modes, but duplication is an inherent capability of an alternate view. It is clear to the user which type of view they have because a new alternating view will be created with all of the possible alternates already in place. A tab control will hence automatically apear, to switch between them. By contrast the duplicating view will be created without the tab control, and then, the tab control will only appear if the user requests a new duplicate view.