Effector 6.3 developer manual

XML reference 6.3

Effector Studio 6.3 summary

Effector Studio 6.3 manual

Effector 6.2 developer manual

XML reference 6.0

Effector Studio 3.2 summary

Effector Studio 3.2 manual


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.

Available features

  • Setting the references of displays/tabs
  • Setting the visibility of displays
  • Configuring the headers/tabs options
  • Setting the style of displays


<Component xmlns="http://effector.hu/schema/ns/component">  
        <Tab id="tab_1">
            <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.

<Tab id="tab_1">
    <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 Tab node.
  • 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.
  • The 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:
    • DisplayDefinition. This is the general data representation display. Grid view, card view, calendar view.
    • Form: It displays an editor form used for data input or viewing detailed data.
    • Chart: used for defining a diagram-type view.
    • EmbeddedWebDisplay: this is an embedded web display used to display a URL, which may be an image, a document preview or an external link.
    • GraphDisplay: graph display, typically used to display flowcharts.


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.

Note! 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 syntactic, 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 true.


Enabling space saving buttons

The two possible values of the /Component/AreSpaceSavingButtonsVisible node are true or false.

Styling views

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.


Screen refreshing

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 true.

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).


Configuring help

Help (which is an URL) can be added for each tabs in Component XML. The following parameters are used by the system:

- ScreenName
- ComponentName
- TabId
- Language


<Tab id="tab1">
<Tab id="tab2">
    <Caption>Grid toolbar (all items)</Caption>

After configuring the help there will be a question mark icon on the given tab. By clicking on it you can open the help.

Help content can be added in Studio on Screen designer and it's saved to FSYS_Help table. The screen/component/tab ID for the given record is stored in the table therefore it's easy to retrieve.

  • Last update: 20 weeks 5 days ago
  • Effector