Layouts

Option Layouts allows to arrange the previously defined widgets on the screen. Thereby the layout definition is always applied to one specific screen section (left/center). For each application several different layouts are possible, which will be activated by different command automatically.
To reduce customizing redundancy layouts can be defined based on other layouts. A layout may inherit its widgets from another layout, but can also overwrite them completely (position, state, visibility etc., see also Widgets in Layouts).

Field	Description

Field	Description
Layout ID	Unique ID of the layout in this application.
Inherited from layout	Definition of a layout, from which all widgets will be inherited.
Area	Definition of screen area in which this widget may be loaded. The activation of the layout in a certain area requires the layout activation (Layouts). The input therefore is rather informative, however will be validated later.
Layout description	Description of layout, will be shown to the user, in case pf user specific changes within the application.

User layouts in the application

Layouts may be adjusted by the user within the application. The widget state can be changed (minimized, normal, maximum display state) as well as the widget size. With the Layout Manager the user can also move, hide or group widgets. User specific changes are saved and restored after restart of the application. Therefore the layouts defined in the customizing are to be seen as examples, which can be changed by the user in any ways.
However it is possible to freeze certain widgets, to prevent the user from deleting essential widgets in the current layout.

Changes in the user layouts by the user have non influence on the inheritance of layout definitions . If a layout which passes on its definition to other layouts is modified by the user, this change has no influence on these other layouts.

If layouts are changed in a productive operation, the user layouts must be reset completely. AFW Administration tools are available.

Layout optimization

When switching from one layout to another, an automatic optimization routine starts, comparing the current and the next layout. If layouts have identical widgets or have widgets excluding each other, the system tries to optimize the state of widgets and widget groups as well as the display hight. This way a layout change will be done smoothly and the main structure of the display on the screen remains the same.

Automatically created layouts

Certain functions are requiring specific widgets in the display. Therefore the system automatically creates a layout in the center section. It includes the Naviagtion widget as well as all other widgets required for the operations. Automatically created layouts cannot be changed by the user with the layout manager.
It is possible to activate own, previously defined layouts by the . However it is necessary to include all relevant widgets in this widgets and it is recommended to fix the widgets, so thy cannot be removed or moved.

Widgets

Assigning widgets to layouts will define positions and some attributes.

Field	Description

Field	Description
Widget ID	Widget defined for this application.
Title	Widget title (automatic, write-protected).
Order	Vertical order in this section.
Group index	As soon as several widgets have the same order, the will be arranged with tabs. The group index defines the order within the tab.
Display status	Default display status. Possible are Normal - normal widget display Maximized - maximized widget display, widget uses entire section Minimized - minimized widget display. Only title bar is displayed, which can be opened by the user Hidden - widget will not be displayed, but can be added by the user, when adjusting the layout Not available - widget will neither be displayed nor can be added by user. Status is mainly used for tests
Abs. height	When setting an absolute height (px), the widget size will be defined independent from the space available and other widgets.
Rel. height	When setting an relative height, the size will be automatically calculated, regarding the relative hight of all other widgets in the current section.
Fixed	When fixed, a widget cannot be removed from the layout.

When grouping multiple widgets (same order) the first widget defines the settings height and status.

Layout Activation

When using several layouts, they must be activated automatically on certain events. Within ProFramework these events are so-called commands, which are triggered almost for all executions of functions. Moreover the activation of a layout can be made dependent on the currently displayed layout.

Field	Description

Field	Description
Area	Defines the area where the layout should be loaded.
Command / Command step	Command and command step which should trigger the layout change. Use the input help F4 to show all possible commands and its steps. Normally a command only defines one step for layout activation. In complex processes more the one step are possible.
Layout ID	Setting a certain layout, the activation depends on the current layout. The new layout will only be activated, when the layout with this ID is currently displayed.
Priority	One command can be set in several layouts for the activation. It makes only sense in a real scenario, when the activation takes place, one with a dependent layout and one without. The activation with binding to a dependent layout must then have a higher priority than the activation without binding to a layout.

Using layout dependency and priority

It is possible that multiple layouts are activated by the same command and step. As soon as there is more than one layout activation, the priority decides about which layout to load. Normally commands and steps should only trigger one layout. Multiple layouts may be helpful to make the customizing more stable by using a general layout for various commands and more specific layouts for certain commands. The more specialized layout is going to overrule the general layout. If the more specific layout is deleted later the application still works with the general layout.

Another scenario is possible by using layout dependencies. Again a general and a more specific layout is defined in which the specific layout includes some of the main widgets of the general layout. To make the UI smoother, little layout changes are preferred. If a command would trigger the general layout and the more specific layout is currently used, a layout change is not necessary because all required widgets are already shown. To achieve this behaviour the more specific layout has to react on the same command and step, but only if the current layout is the layout itself. This layout activation will never trigger a layout change but prevent a more generic layout to be loaded.

Transformation

In addition to layout changes, the tabs to be selected can be controlled by transformation. However the relevant widgets must be grouped. This is always recommended, when a layout is reacting on several commands. This way it is possible to guarantee the automatic selection of certain widgets. This helps reducing the number of layouts, because one layout can contain several widgets for multiple intended applications.

Field	Description

Field	Description
Run No.	Unique number
Application widget ID	Widget ID
Selected	If widgets are displayed with tabs, this flag defines the default selection of the tab.