User Management
6 User Management
The TwinCAT User Management enables the implementation of a permissions system in order to control the
user group-specific access at control, symbol or file level.
The use of the User Management functions is optional and works only with active authentication.
Since the User Management only works with active authentication, the configured functions are not
available in the live view.
6.1 Users and user groups
The TwinCAT HMI User Management is based on a user group concept. The user groups are managed
centrally in the TwinCAT HMI Server (TcHmiSrv). The actual users, who may be members of one or more
user groups, are made available as a data source by the server extension TcHmiUsermanagement. The
creation and editing of users and user groups takes place within the development environment via the
TwinCAT HMI Configuration window under the category Users and Groups, within which the individual
Users and Groups are listed.
6.1.1 Create new user
1. Select Create new user with a right mouse click on Users, or the Create User function with a left mouse
click.
2. Configure the user with the following properties in the associated dialog:
User name: Unique name
Password: Login password
Confirm Password: Confirmation of the login password
Language: Default language to be set on logging in
Member of the following groups: Group memberships (selection of the existing groups; user can be a
member of several groups, but must be a member of at least one project-specific group)
Auto-Logout after: Period of inactivity (client side, i.e. no user interaction) after which the user is
automatically logged out
3. Confirm your settings with OK.
6.1.2 Changing user properties
1. Double-click on the user whose properties you wish to change or right-click on Edit user.
2. Make the desired changes (see Create new user [} 507]).
6.1.3 Deleting a user
1. Select Delete User by right-clicking on the user to be deleted.
6.1.4 Creating a new user group
1. Select Add new group by right-clicking on Groups, or the Create new group function with a left mouse
click.
2. Configure the user group with the following properties in the associated dialog:
Group name: Unique name
Symbol Access: Standard symbol access (None, Read, Write, Read/Write)
File Access: Standard file access (None, Read, Write, Read/Write)
Status: Active status of the group (Enabled, Disabled)
Members: Group members (selection of the existing users)
3. Confirm your settings with OK.
6.1.5 Changing user group properties
1. Call the dialog by double-clicking on the user group whose properties you wish to change, or by a right
mouse click on it via Edit group.
2. Make the desired changes (see Creating a new user group [} 509]).
6.1.6 Deleting a user group
1. Select Delete Group by right-clicking on the user group to be deleted.
6.1.7 System users and system user groups
The following users and user groups exist as standard in the system and cannot be deleted:
System user
__SystemAdministrator: System administrator and member of the group "Systemadministrators".
__SystemGuest: Guest who is automatically active if no user is logged in and is a member of the group
"SystemGuests".
System user groups
__SystemAdministrators: System administrator group with unrestricted rights and the following default
settings:
Symbol Access: Read/Write
File Access: Read/Write
Enabled: True
Members: __SystemAdministrator
__SystemGuests: Guest group with restricted rights, which allow only the login function, and the following
default settings:
Symbol Access: None
File Access: None
Enabled: True
Members: __SystemGuest
__SystemUsers: User group with restricted rights that allow access to all system server symbols required at
runtime. The user group has the following default settings:
Symbol Access: None
File Access: None
Enabled: True
Members: Every user except __SystemAdministrator or __SystemGuest
By default, all new users are members of the group __SystemUsers as a minimum. This behavior can be
changed on the server configuration page under TcHmiSrc/General > "Default Usergroup".
The system users and system user groups are visible and configurable only in Advanced Mode.
6.2 Permissions system
You can issue user group-specific permissions at three levels in the permissions system of the TwinCAT HMI
User Management.
1. The control level [} 511] represents the client-side permissions system of the TwinCAT HMI Framework.
This is a manipulation of the user interface through the hiding of controls or the deactivation of
their functions, depending on which group(s) the logged-in user belongs to.
2. The symbol level [} 515] controls the user group-specific access to server symbols (mapped symbols).
3. The file level [} 516] enables the user group-specific access to the files made available by the Twin-
CAT HMI Server.
While level one is purely a manipulation of the user interface on the client side, the second and third
levels offer real data security on the server side.
In order to be able to configure the rights of the system user groups at the individual levels, you
have to activate Advanced Mode in the TwinCAT HMI Configuration window.
6.2.1 Control level
The control level represents the client-side permissions system. A control has defined access methods that
can be permitted or not permitted for the different user groups. Each control has at least the default access
methods "Observe" and "Operate".
"Observe" describes the general observability of the control and thus its visibility to the user. If this access
method is not permitted for the user group of the logged-in user, the control is not visible. This also applies to
all child controls of the control, if there are any.
"Operate" represents the general operability of the control. If this access method is not permitted for the user
group of the logged-in user, then the control is displayed as deactivated and no control events that could be
initiated by the user (operator events) are initiated.
The access methods are configured in the Properties window (Configuring control access [} 511]).
The access methods of a user control can be extended via special access methods, so-called virtual
permissions (Defining and using virtual permissions of a user control [} 513]).
6.2.1.1 Configuring control access
1. Select the control in the designer.
2. Open the Show Permissions tab in the Properties.
3. Configure the desired permissions of the individual user groups; the following options are available for
this:
Allow: The access method is permitted for the user group.
Disallow: The access method is not permitted for the user group.
Inherit: The permission of the user group is derived from the higher-level parent control (container
control: View, Content, User Control, Container, Region or User Control Host).
Special cases
Access methods of a view
Operate and Observe are permitted for a view as standard (default = Allow). Since the view –as the entry
point to the HMI application –is always the highest container control, the Inherit option is not available.
User is a member of several user groups
The following rules apply if the user is a member of several user groups:
· If Allow is configured for at least one user group, the access method is permitted for the user (Allow).
· If Disallow is configured for at least one user group and Allow is not configured for any user group, the
access method is not permitted for the user (Disallow).
· If Inherit is configured for all user groups, the permission is derived from the higher-level container
control (Inherit).
6.2.1.2 Defining and using virtual permissions of a user control
Defining virtual permissions
1. Open the parameter editor of the user control.
2. Under Virtual Permissions, add the desired additional user control access methods. The following
properties can be configured here:
Name: Unique name of the virtual permission
Description: Description used as a tooltip
Additional properties are displayed if you activate the Details checkbox:
Internal Name: Internal name used in HTML code (corresponds by default to "Display Name").
Display Name: Name displayed to the user in the engineering (corresponds by default to "Name").
Visible: Visibility of the virtual permission for the user in the engineering.
Default Value (Internal): Default return value of the virtual permission if the query of the current
permissions situation does not produce a return value.
3. Confirm your input with OK.
Using virtual permissions
4. Select a control inside the user control in the designer.
5. Assign a virtual permission for the desired access method to the selected control, which is to represent a
special access method of the user control to the outside.
The desired access method is now no longer configurable inside the user control. However, it is available for
configuration through the assignment of the virtual permissions as an additional access method of the user
control host when using the user control in the designer.
For the purpose of reusability of the user control, direct configuration of the access methods inside
a user control should be dispensed with. The independence of project-specific user groups is
achieved with this approach. Accordingly, the default access methods "Observe" and "Operate"
should be configured either with "Inherit" or as special access methods via the use of virtual permissions.
Special access methods of controls within a user control should always be fed to the outside
via the use of virtual permissions because the user control host only has the default access methods
"Observe" and "Operate" as standard.
6.2.2 Symbol level
The symbol level represents the first part of the server-side permissions system. General and user groupspecific
access methods, which apply when authentication is active, can be configured for every mapped
server symbol (Mapped Symbols). The configuration is done via the Permissions Management editor, which
can be called via the TwinCAT HMI Configuration window (Configuring symbol access [} 515]).
6.2.2.1 Configuring symbol access
1. Select the Symbol Permissions tab in the Permission Management editor.
2. Configure the following access methods for a mapped server symbol:
Symbol Access: Generally permitted symbol access method that is valid for each user group (default
value: Read/Write).
Group Symbol Access: Permitted default access method of a user group for all symbols (see also
Creating a new user group [} 509]).
Specific Group Symbol Access: Permitted user group-specific access method for the symbol that is
initially specified by the combination of Symbol Access and Group Symbol Access, whose
configurations mutually restrict each other.
However, it is also possible to overwrite this combination so that Symbol Access and Group Symbol
Access are invalid for this symbol for this user group.
3. Confirm your configuration with OK
Special cases
User is a member of several user groups
If a user is a member of several user groups, the combination of permitted access methods of the user
groups applies, which in this case mutually expand one another.
The permitted access methods for system server symbols can be configured in Advanced Mode.
6.2.3 File level
The file level represents the second part of the server-side permissions system. General and user groupspecific
access methods, which apply when authentication is active, can be configured for every file and
every folder added to the TwinCAT HMI Server via the publishing. The configuration is done via the
Permissions Management editor, which can be called via the TwinCAT HMI Configuration (Configuring file
access [} 517]).
6.2.3.1 Configuring file access
1. Select the File and Folder Permissions tab in the Permission Management editor.
2. Configure the following access methods for a file (or a folder):
File Access: Generally permitted file access method that is valid for each user group (default value:
Read/Write).
Group File Access: Permitted default access method of a user group for all files (see also Creating a
new user group [} 509]).
Specific Group File Access: Permitted user group-specific access method for the file that is initially
specified by the combination of FileAccess and Group File Access, whose configurations mutually
restrict each other.
However, it is also possible to overwrite this combination so that File Access and Group File Access
are invalid for this file for this user group.
3. Confirm your configuration with OK
Special cases
User is a member of several user groups
If a user is a member of several user groups, the combination of permitted access methods of the user
groups applies, which in this case mutually expand one another.
6.3 User Access Handling Functions
The system provides the following functions for use in the User Management area in the development
environment:
Logout
Function for logging out the logged-in user from the TwinCAT HMI Server (result if execution is successful:
login page is loaded).
Check Access
Function for querying whether a certain control access method is permitted for the logged-in user or not.
7 Event system
The central event system is integrated in the TwinCAT HMI server. It is possible to manage events from the
HMI server and its extensions. In addition, the TcHmiEventlogger [} 519] extension can be connected with
the TwinCAT 3 event logger from local or remote real-time systems.
The EventGrid Control [} 520] can be configured flexibly and used to display current or historical events.
Available since version 1.10
7.1 TcHmiEventlogger extension
When creating a new TwinCAT HMI project the TcHmiEventLogger extension is also loaded and is located in
the project under the server node with the Extensions [} 109].
Configuration
In the TwinCAT HMI server configurations you can configure the event logger with which the Engineering
HMI Server (Publish Configuration: Default) or the Remote HMI Server (Publish Configuration: Remote)
communicates. By default the extension connects to the local TwinCAT 3 event logger. Remote target
systems can also be entered if the ADS route is configured.
Licensing
One target license is counted per event logger. If an ADS connection is also configured with the same NetId,
only one target license is counted.
7.2 Event Grid Control
The Event Grid Control is a control for the tabular display of alarms and messages. It automatically displays
the alarms and messages of the target systems addressed in the event logger extension. Alarms can be
confirmed directly in the control.
The Event Grid Control is located in the Toolbox under the category Beckhoff, from where you can insert it
into an HMI page by drag-and-drop.
Apart from the tabular display of the alarms and messages, the control offers various configuration options in
the engineering and during the runtime in the browser.
Detailed view
A detailed view can be displayed for each message and alarm in the Event Grid. The detailed view is opened
by selecting a row in the Event Grid and double-clicking on the row. The detailed view provides additional
information about the event.
Filter
Filters enable the display of alarms and messages according to certain criteria. It is possible, for example, to
display only active alarms or to filter according to a certain time period. The filters can be configured under
Filter [} 227] in the control's properties.
You can switch between different filters at runtime by calling a WriteToSymbol [} 51] for the filter of the Event
Grid. Alternatively, you can use various filter settings via the control's menu bar [} 230].
Columns
The configuration of the columns defines which columns are displayed in the Event Grid Control. By default
the type (alarm or message), the severity, the timestamp of the input and the associated text are displayed.
Further columns such as the time of the confirmation can be configured in the control's properties [} 228].
The settings apply to all clients.
There is an option at runtime to change the columns displayed per client. To do this, open the column editor
from the menu bar [} 230]. The column editor automatically opens a popup with an overlay and positions
itself in the center of the view:
Confirming an alarm
An alarm can be confirmed by selecting the row containing the alarm and clicking on the button Confirm
alarm (single check mark) in the menu bar [} 230].
If several alarms are active, there is an option to confirm all alarms simultaneously. To do this, click on the
button Confirm all alarms (two check marks) in the menu bar [} 230]. A popup with an overlay then opens
automatically and displays all active alarms. At this point the operator has the option to abort the dialog or to
confirm the active alarms.
Permissions
Within the context of an authorization system it may be useful to allow only certain operators to access the
Event Grid. In addition, individual operators may be assigned rights to confirm the events. Rights are
configured in TwinCAT HMI at two levels (see User Management [} 507]).
At control level the configuration right (configuration at runtime) and the right to a detail view can be granted
[} 230] explicitly in addition to the standard rights for the Event Grid.
The right to confirm the alarms can be granted at symbol level. To do this, open the rights management
[} 515] in the expert view.
Further configuration options
Further configuration options for the Event Grid Control can be found here [} 222].
Example
An example of the use of the event logger with the Event Grid: https://infosys.beckhoff.com/content/1033/
TE2000_TC3_HMI_Engineering/Resources/zip/5239743115.zip
The example shows two different configuration options for the Event Grid and the associated PLC project, in
which example alarms and messages can be generated.
8 Internationalization
8.1 Change the language
The localization files of a TwinCAT HMI project can be found in the Solution Explorer [} 40]. You can
manage language entries via the Localization editor [} 86] or the TwinCAT HMI Configuration [} 63] window.
You can add new languages to the project as a new TwinCAT HMI Item [} 122]. The configuration of Change
the language [} 33] is described in the Quick start [} 26].
8.2 Unit conversion
The conversion of the units can be initiated flexibly via Functions [} 93]. The conversion of the units can take
place by querying the active language via the GetLocale function [} 56]. Alternatively the units can also be
converted irrespective of the language via an internal symbol [} 71].
9 Themes
The theme system allows you to switch the design of all elements. The theme can be switched during
runtime per client or globally in the project properties. Only one theme can be active at a time (similar to
language switching [} 524]). A theme can change the appearance of a control (e.g. Top [} 426], Left [} 426],
Width [} 427], Height [} 428], BackgroundColor [} 433] etc.). Besides the appearance of the control, all
control attributes [} 125] can be changed.
A theme can be created via the integrated theme editor or directly as a CSS file.
Available since version 1.10
9.1 Introduction
In a TwinCAT HMI project, the various themes are located under the Themes project node:
The theme node contains all themes defined for the project. For each theme there is a .theme file, which
contains the JSON definition of a theme and can be opened with the theme editor.
The default theme can be viewed and switched under the general project properties (click on the project
node and open the Properties window).
For a new project, the base theme is included in the project and set as the default theme. The base theme
includes the font setting, which is included at project level regardless of the theme (see Fonts). In addition,
each TwinCAT HMI Control has a base theme, which describes the design of the control if this is not
explicitly overwritten by the developer in Engineering or by another theme.
Add a new theme by right-clicking on the Themes project node under New\Add New Item. In the dialog
select the type Theme and click Add.
The new theme contains the .theme file, which can be opened via the theme editor [} 527].
Under a theme, right-click Add Item to add more items.
You have a choice between a Cascading Style Sheets file and a CSS control theme file (see CSS theme
[} 532]).
9.2 Theme editor
Open the theme editor by double-clicking on a .theme file in a theme. The following graphic shows the theme
editor, which is open for the basic theme as an example.
The theme editor is divided into the following areas:
1 Status information (Attribute Values for Control Type Button):
· Default theme: Here you can set the default theme (as in the project properties).
· View: Determines which attributes are displayed. In the standard view, only those attributes and
controls are displayed that are usually changed by the user. The Advanced view displays all controls
that can be changed and their attributes.
2 Theme Control Types and Classes: In this area you can select whether a Class theme [} 528] or a
Control theme [} 531] should be edited.
3 Themeable Attributes: In this area you select for which attribute a property is to be defined, depending on
the respective theme.
Only those attributes are displayed that can be changed via the theme.
4 Attribute Properties: In this area, the property for the respective attribute is set. Any number of properties
can be set for each Class theme and each Control theme.
9.2.1 Class theme
A class theme defines properties that apply to all controls assigned to this class, regardless of the control
type. A control class is defined at project level for each theme in the theme editor.
The following steps are required to create a class theme:
1. Open a theme in the theme editor, right-click on Control Classes and select Create new Control Class:
2. Added control classes that do not yet contain definitions are initially grayed out in all themes:
3. You can define any number of attribute properties for a control class. All control attributes are available:
4. The control class must be assigned to a control for the properties to apply to the control. Open the
Properties window for a control and select the entry ClassNames under Common:
5. In the dialog, select the control classes that you want to add to the control. To do this, select the required
control class and press the arrow. Confirm the dialog with OK:
ð The control class is now assigned to the control, and the properties of the control class are used.
If you add several classes to a control and each class describes the same attributes, the properties
of the last class in the list apply (analogous to the class selectors in CSS).
To display the attribute properties of the class theme, the attribute must not be explicitly set at the control.
The control colors must be set to Theme.
9.2.2 Control theme
A control theme defines the properties for all instances of a control. The control theme is defined for each
theme in the theme editor [} 527] at project level.
The following steps are required to create a Control theme:
1. First, the control type must be selected in the theme editor. In the upper screenshot the control type
Button was selected.
2. After selecting the control type, select the attribute from the respective changeable attributes.
3. Drag and drop the attribute onto the large area for the attribute properties in the center of the editor.
4. You can define any number of additional attributes for the control type.
Control types that contains defined attribute properties are shown in bold font. To change the attribute
properties for a control type at a later stage, select the respective control type again. The existing
configurations are then automatically displayed in the center of the theme editor. A property that has already
been configured can be deleted by selecting it and then pressing the Delete key.
To display the attribute properties of the Control theme, the attribute must not be explicitly set at the
control. The control colors must be set to Theme.
9.2.3 CSS theme
Beside the control theme and the class theme there is the possibility to add [} 525] any number of Cascading
Style Sheets files to a theme. A distinction is made between a normal CSS file and a CSS control theme file.
CSS files can also be added at project level, independent of a theme. These files define general properties
such as the inclusion of fonts.
Cascading Style Sheets file
A Cascading Style Sheets file allows the definition of any CSS properties for all elements contained in the
project (standard controls, framework controls etc.). In addition, specific CSS classes can be overwritten by a
control. All CSS selectors and CSS properties are available within a CSS file.
If a class theme [} 528] is defined in the theme editor, it can be addressed in the CSS code via the class
name with the prefix tchmi-class-. Example:
tchmi-class-myclassthemeclass
CSS control theme file
A CSS control theme file can be used to replace specific CSS properties of the base theme. This is made
possible by importing all CSS properties of the control into the CSS control theme file of the project.
In the next window you have to select the control for which you want to create a CSS control theme file.
In this dialog you can select several controls for which a CSS control theme is to be generated. You must
also select from which theme the CSS control theme should be derived. If you select the Base theme, all
properties defined in the Base theme of the control are displayed.
Some controls contain further TwinCAT HMI Controls, e.g. the Event Grid. This is indicated in the dialog by a
note (upside down exclamation mark) after the control. If you want to overwrite all properties, you must also
include the CSS files of the child controls. For more detailed information about the dependencies between
the individual controls, see the documentation for each control.
The following example shows a CSS control theme file for the control TcHmiButton [} 160]:
/** Styles for the theme: Base */
/* Style for the main element */
.tchmi-button {
/* color gradient for default view */
background-image: linear-gradient(135deg, #eff1f3, #aeb9c2);
/* default color for button text */
color: #4794da;
/* default box shadow */
box-shadow: 0px 0px 5px 0px rgba(0,0,0,0.6);
}
/* class down will be set/unset in the control on mouse/touch down */
.tchmi-button.down {
/* another color gradient */
background-image: linear-gradient(135deg, #aeb9c2, #eff1f3);
color: #000000;
box-shadow: inset 0px 0px 5px 0px rgba(0,0,0,0.6);
}
9.3 Theme switching
You can switch the entire theme in the project properties, the theme editor or during runtime using a function.
Controls allow you to switch between different theme classes within a theme at runtime. Individual control
attributes can be assigned a theme property at runtime if they have been overwritten previously.
Switching in the properties
The default theme can be viewed and switched under the general project properties (click on the project
node and open the Properties window).
The theme editor [} 527] features the Default Theme property in the header bar at the top, irrespective of
the theme. There you can set the default theme in the same way as in the project properties.
Switching at runtime
The theme can be switched during runtime in the browser for each client [} 15]. To do this, an action must be
configured, e.g. on the .onPressed event of a button (so that the theme is switched when a specific button is
pressed). In the Actions and Conditions editor, the Theme folder contains the SetTheme function under
functions. Use drag & drop to add this function under the actions and enter the name of the theme by
selecting it in the combo box.
Switching classes
In certain cases it is necessary to switch not the entire theme, but only the properties of a group of elements
or a particular control instance during runtime. This is possible if different theme classes [} 528] are defined
for the control. During runtime the attribute ClassNames [} 425] of the control is then set again. To do this, an
action must be configured at runtime, as for theme switching.
Switching from control attributes to a theme
A control attribute, which is set by an attribute definition directly at the control (Level 1 [} 536]), can be set to
the value of the currently active theme during runtime with the SetAttributeToThemeValue [} 104] function.
The value of the attribute is then changed according to the active theme each time the theme is switched.
This function is used if individual control attributes are to be overwritten and then reset to the value
of a theme.
9.4 Concept
Theming in TwinCAT HMI distinguishes between control-based themes and class-based themes. A control
theme [} 531] specifies properties that apply to all instances of the respective control type. A class theme
[} 528] specifies properties that only apply to controls to which this class is assigned. You can assign several
classes to a control.
The theme properties can be set at different levels. Cascading Style Sheets use a comparable approach in
the sphere of web development, for example. The levels determine which property applies to an element if
different properties are defined for an element. The properties of the higher levels are overwritten by the
properties of the lower levels, if these are defined. The lowest level is level 1, which overwrites all properties
of the higher levels.
The theme system has the following levels:
Level 1: Attribute level [} 538]
This level describes the appearance using attribute definitions at the control. In analogy to the CSS world,
this level would be a "style" attribute that is defined directly at the element.
Levels 2-4: attribute levels [} 538]
Like level 1, these levels describe the appearance using attribute definitions at the control. In analogy to the
CSS world, these levels would be external CSS files.
Level 5: attribute levels [} 538]
Like levels 1-4, this level describes the appearance using attribute definitions at the control. If nothing is
specified above levels 1-4, this defaultValueInternal value applies. In the analogy to the CSS world these
levels would be comparable to the font color black, for example, which applies even if nothing else has been
defined.
Levels 6-9: element levels [} 538]
These levels describe the appearance of a control using Cascading Style Sheets files if the appearance of a
control cannot be defined using an attribute or has not been defined using an attribute.
9.4.1 Attribute levels
The attribute levels describe the appearance of the controls using attribute definitions.
Level 1: Attribute definition at the control at project level
The attribute definition on a control instance overwrites all properties defined by a theme. The attribute
definition at the control [} 125] is specified in the Properties window or directly in the HTML code. The
attribute definition at the control follows the usual procedure for overwriting the default properties of the base
theme if no other theme is defined.
This option has been available since version 1.8.
Level 2: Attribute definition in a class at project level
The attribute definition in a class [} 528] is specified in the theme editor of the respective theme at project
level. The class is added to a control as a property so that it automatically adopts the attribute definitions of
the class. The attribute definition in a class overwrites the attribute definition for a control type if both
definitions contain the same attribute.
Level 3: Attribute definition per control type at project level
The attribute definitions in a control type [} 531] are specified in the theme editor of the respective theme at
project level. The attribute definition in a control type applies to all instances of the respective control in the
project and is only overwritten by level 1 or level 2.
Level 4: Attribute definition per control type at control level
The attribute definition per control type at control level [} 2035] is specified directly in the directory of the
control and is defined by the control developer. The definition is the same as in level 2 within a .theme file.
For the standard controls, this property cannot be changed at the control level. The attribute definition per
control type at control level is therefore only available for framework control developers.
Level 5: Attribute definition through DefaultValueInternal at control level
The DefaultValueInternal [} 2028] defines the properties of an attribute independent of the active theme and is
used if the attribute is not overwritten by a theme at the higher levels.
In addition to the attribute definitions, it is possible to configure so-called ThemedResources at levels 2 to 4.
The ThemedResources are control properties that cannot be configured via the Properties window and can
only be changed via the theme system. An example of this are the knob definitions [} 313] at the
LinearGauge. The definition [} 2029] of ThemedResources is handled by the control developer.
9.4.2 Element levels
The element levels describe the appearance of the controls using Cascading Style Sheets files.
Level 6: Cascading Style Sheets per theme at project level
At project level it is possible to add, in addition to the .theme file of the theme editor, any number of CSS files
to a theme in the project (see Introduction [} 525]).
If a control is described in the theme editor and also in a CSS file within the theme, the definitions
within the theme editor (lower level) apply.
Level 7: Cascading Style Sheets at project level
At the project level, any number of Cascading Style Sheets files can be defined, independent of a theme.
This option has been available since version 1.8 under the name CSS-Behind file. The definitions within the
CSS file at the project level overwrite the CSS definitions at the control level and apply regardless of the
theme.
Any CSS-Behind files at project level, which were already added to the project with version 1.8,
can still be used. When using different themes, it usually makes sense to assign this file to a specific
theme.
Level 8: Cascading Style Sheets per theme at control level
Any number of Cascading Style Sheets files can be added to a theme at the control level. The CSS
definitions at control level describe the normal layout of all elements of a control. These properties apply if no
properties of the control are overwritten by a theme at the higher levels. Each control should implement at
least one theme called Base.
Level 9: Cascading Style Sheets at control level
At the control level, you can add any number of general Cascading Style Sheets files that describe the
properties of elements, regardless of the theme._