As discussed previously, screens are built of components, which components contain the display objects. At once, only one display is visible, the others are accessible through tabs.
Generally speaking, while menus are related to different activities, where the activities are grouped according to functions, the tags on the components usually work with the same dataset but by using diverse display methods, they present different aspects of the data.
What does it mean?
As an example, we can define for our sales staff a general screen that features the projects, the related events and the persons involved in the individual events. This is a classical PEP (Project-Event-People) screen. On the
Projects display, we can define a
Projects table, while on an adjacent tab, one’s own ongoing projects can be placed on a card view arranged according to likelihood. This way sales persons can easily switch to the tab and view their undertakings. Of course, there are several other ways to accomplish this in the system.
- Setting the references of displays/tabs
- Setting the visibility of displays
- Configuring the headers/tabs options
- Setting the style of displays
<Visible type="SQL" return="boolean">
SELECT CASE WHEN '[##Filter.Type##]'='Special' THEN 'False ELSE 'True' END
<Tab id="tab_2" important="true">
The definitions of tabs/displays are set in (
Component/Tabs/Tab/ResourceName) nodes. The example above defines a grid view to the
Participants tab which will appear if the event is an
Event in the filter passed. When connected to a different event, the tab disappears.
<Visible type="SQL" return="boolean">
SELECT CASE WHEN '[##Filter.EventType##]'=Event THEN 'False ELSE 'True' END
Nodes used for defining tabs:
- Each tab must have a unique ID within the file, which can be given by setting the
ID attribute of the
- A tab that is not the first (visible) tab can be made active by default by setting the value of its
important attribute to
True. If we define several tabs as important, the first in the row will be active by default.
- The cation of the tab can be specified by setting the value of the
Tab/Caption node. It does not have to be unique.
Tab/ResourceName node contains the reference of the display related to the tab. Its value is an appropriate file reference, that is a file name without extension. Possible view types:
If we ensure by using visibility rules that tabs having identical names can be displayed one at a time, we can define several tabs bearing the same name, the user will not notice the change. For example, if we would like to present certain users with more data or present them differently, it is feasible on the component level. We simply define various types of views and set their visibility per user as shown above.
The order of the tabs will coincide with that of the
Tab nodes in the XML.
Controlling the visibility of displays
- Setting a visibility rule is not mandatory, by default, a tab is always visible. The visibility rule can be set in the
Tab\Visible node, as for syntactics, it is of
RuleValueType, on which further information can be found in Rules.
Setting the visibility of header/tabs
The component header can be easily switched off in the system by setting the value of the
/Component/IsHeaderVisible node to
false. In such a case, the header and tabs disappear, while the function buttons on the header (counter, resize, etc.) remain visible. This is useful if we need to save space on a component, where a single view/tab is defined.
Visibility of the header’s function buttons
To spare space, it is also possible to hide the function buttons in the header of certain tabs by setting the value of the
/Component/AreHeaderButtonsVisible node to
false. By default, these buttons are visible in the header.
Displaying multiple tabs
If a component features more tabs than can be displayed, their visibility can be adjusted by using the
Component/TabOverflowType tag. Its possible values may be:
- BreakingLine: tabs are displayed in multiple rows
- DroppingDown: the desired tab can be selected from a dropdown list
- Shrinking: tabs are resized so that they can fit in one row. The caption of the active tab is always fully visible.
- ShrinkingWithHover: similar to Shrinking except here the whole tab appears when the mouse cursor is hovering over it. The default value is ’shrinking`.
Closing pop-up windows with ESC key
By default, pop-up windows get closed when the ESC key is pressed. This feature can be disabled by setting the value of the
/Component/IsESCEnabled node to
false. Optional setting. It defaults to
Enabling space saving buttons
The two possible values of the
/Component/AreSpaceSavingButtonsVisible node are
View objects can be styled simply by setting the
\Tab\CssClass node. The CSS style stated here has to be defined in the ui/gfxstyle.css file in the application folder and will be applied to the view of the given tab when displayed, changing its default appearance.
When closing a pop-up window (by pressing the
x close button in the upper-right corner), the screen beneath it (the one from which the pop-up window was opened) can be refreshed if the value of the
Component\Tab\RefreshParentOnClose node is set to
true. The default value is
This setting has to be specified on the panel tab that is active when the close button is pressed.
This has importance when the data displayed on the underlying screen changes as a result of the data processing done in the pop-up window and such changes are to be shown immediately.
It is important that if the pop-up window is a form editor (EditForm), and it features a save or delete button, the screen beneath it gets automatically refreshed once any of these buttons are pressed. The
RefreshParentOnClose option is useful in case of types of buttons other than save/delete (such as
back or the
x close button in the upper-right corner of the pop-up window).