Environment Editor/en - Versionsgeschichte

Cg: /* Fields */

2026-04-24T17:19:08Z

Fields

← Nächstältere Version		Version vom 24. April 2026, 17:19 Uhr
Zeile 21:		Zeile 21:

	;OW (overwrite)		;OW (overwrite)
	:This check box determines whether the variable hides (overwrites) an inherited variable from an outer scope, or not. This option/column is only shown for compound blocks. The default mode is "overwrite", so variables behave as if defined in a lexical scoped fashion: variables can be redefined in a compound block to overwrite any outer definition of the same named variable.<br>The non-overwrite mode is useful if a block wants to define a variable's fall back or default value, to be used if no outer definition exists. <br>For example, an interface block which needs a port number (e.g.. an HTTP port number) might define the variable as a non-overwriting local variable, with a value of "80". If an outer block or the test suite needs a different parameter, it is free to define HTTP Port with another value (see also "Hints & Tricks" below).		:This check box determines whether the variable hides (overwrites) an inherited variable from an outer scope, or not. This option/column is only shown for environments of compound blocks. The default mode is "overwrite", so variables behave as if defined in a lexical scoped fashion: variables can be redefined in a compound block to overwrite any outer definition of the same named variable.<br>The non-overwrite mode is useful if a block wants to define a variable's fall back or default value, to be used if no outer definition exists. <br>For example, an interface block which needs a port number (e.g. an HTTP port number) might define the variable as a non-overwriting local variable, with a value of "80". If an outer block or the test suite needs a different parameter, it is free to define HTTP Port with another value (see also "Hints & Tricks" below).

	;R/W (read/write)		;R/W (read/write)

Cg: /* Constant */

2026-04-24T17:16:26Z

Constant

← Nächstältere Version		Version vom 24. April 2026, 17:16 Uhr
Zeile 55:		Zeile 55:
	:The following section on variable expansion applies to both environment variables and freeze values.		:The following section on variable expansion applies to both environment variables and freeze values.

	: Use "$(''Name'')" to refer to the value of the variable named "''Name''". The parenthesis are required. Thus if your environment contains a variable "Foo", with value "Hello", the value "$(Foo)World" will expand to "HelloWorld" whereas "$Foo World" remains as is.<p>Be careful when referring to variables from within the same environment in environments: these are initialized top-to-bottom, and values of variables further down the list will be set later.		: Use "<code>$(''Name'')</code>" to refer to the value of the variable named "''Name''". The parenthesis are required. Thus if your environment contains a variable "Foo", with value "Hello", the value "$(Foo)World" will expand to "HelloWorld" whereas "$Foo World" remains as is.<p>Be careful when referring to variables from within the same environment in environments: these are initialized top-to-bottom, and values of variables further down the list will be set later.

	: If the variable is a compound action block's local variable (i.e. not a project-global or testplan/testcase-item variable), then the action's pin values are accessible as "$(''pinName'')".		: If the variable is a compound action block's local variable (i.e. not a project-global or testplan/testcase-item variable), then the action's pin values are accessible as "$(''pinName'')".

Sv am 13. November 2023 um 11:43 Uhr

2023-11-13T11:43:19Z

← Nächstältere Version		Version vom 13. November 2023, 11:43 Uhr
Zeile 8:		Zeile 8:
	By default, an inner variable (i.e. from a deeper nesting) shadows a corresponding outer variable, but this behavior may be reversed for special situations, where an inner variable is used to provide a fallback value for testing.		By default, an inner variable (i.e. from a deeper nesting) shadows a corresponding outer variable, but this behavior may be reversed for special situations, where an inner variable is used to provide a fallback value for testing.

	Also environment variables defined in a testsuite overwrite variables with the same name in imported libraries (see [[#Scope of Environments\|scope]]). This feature allows to modify the behavior of imported libraries by overwriting variables. A best practice is to always use unique names for variables in libraries. Otherwise e.g. defining a variable "timeout" in a ~~testsuite~~ ~~would~~ affect one or even more imported libraries using the same variable name.		Also environment variables defined in a testsuite overwrite variables with the same name in imported libraries (see [[#Scope of Environments\|scope]]). This feature allows to modify the behavior of imported libraries by overwriting variables. A best practice is to always use unique names for variables in libraries. Otherwise e.g. defining a variable "timeout" in a test suite could affect one or even more imported libraries if they are using the same variable name.

	== Fields ==		== Fields ==

Sv am 13. November 2023 um 11:39 Uhr

2023-11-13T11:39:56Z

← Nächstältere Version		Version vom 13. November 2023, 11:39 Uhr
Zeile 5:		Zeile 5:
	Environment variables can be used as input to a step by setting an input pin's input value (freeze value) to "''Read from Environment''" via the pin's menu. The standard library also contains a number of blocks to access environments and to dynamically add, remove, read or modify environment variables.		Environment variables can be used as input to a step by setting an input pin's input value (freeze value) to "''Read from Environment''" via the pin's menu. The standard library also contains a number of blocks to access environments and to dynamically add, remove, read or modify environment variables.

	Environments are arranged as a hierarchy of local environments (scope), so that an inner block's variable may hide an outer block's variable, up to the containing test plan and finally the test suite's environment.		Environments are arranged as a hierarchy of local environments ([[#Scope of Environments\|scope]]), so that an inner block's variable may hide an outer block's variable, up to the containing test plan and finally the test suite's environment.
	By default, an inner variable (i.e. from a deeper nesting) shadows a corresponding outer variable, but this behavior may be reversed for special situations, where an inner variable is used to provide a fallback value for testing.		By default, an inner variable (i.e. from a deeper nesting) shadows a corresponding outer variable, but this behavior may be reversed for special situations, where an inner variable is used to provide a fallback value for testing.

			Also environment variables defined in a testsuite overwrite variables with the same name in imported libraries (see [[#Scope of Environments\|scope]]). This feature allows to modify the behavior of imported libraries by overwriting variables. A best practice is to always use unique names for variables in libraries. Otherwise e.g. defining a variable "timeout" in a testsuite would affect one or even more imported libraries using the same variable name.

	== Fields ==		== Fields ==
Zeile 147:		Zeile 149:

	==== Notes on "From User" initialization ====		==== Notes on "From User" initialization ====
	These will ask the user via an interactive UI-dialog. The boxes question text can be customized by adding lines starting with "<code>#></code>" (hash-greater) to the variable's comment. These lines will be extracted from the comment and concatenated to form a ~~multiline~~ question string.		These will ask the user via an interactive UI-dialog. The boxes question text can be customized by adding lines starting with "<code>#></code>" (hash-greater) to the variable's comment. These lines will be extracted from the comment and concatenated to form a multi line question string.

	==== Notes on "When First Used" initialization ====		==== Notes on "When First Used" initialization ====
Zeile 254:		Zeile 256:
	See [[Command_Line_Options#Test_Parameters \| "Command Line Options"]].		See [[Command_Line_Options#Test_Parameters \| "Command Line Options"]].

	== Special (~~Wellknown~~) Variables ==		== Special (Well known) Variables ==

	The GUI-Browser subsystem can store xPath locators in the top level environment, to provide a mapping from widget-names to locators.		The GUI-Browser subsystem can store xPath locators in the top level environment, to provide a mapping from widget-names to locators.
Zeile 303:		Zeile 305:
	* the system environment (read only)		* the system environment (read only)
	* the test suite's environment		* the test suite's environment
	* the environment of the project in which the currently executing compound activity's action is defined		* the environment of the project (e.g. imported library) in which the currently executing compound activity's action is defined

	The standard library provides additional action blocks to manipulate some of those environments,		The standard library provides additional action blocks to manipulate some of those environments,
	others are ~~readonly~~.		others are read only.

	==== Hidden Environments ====		==== Hidden Environments ====

Cg: /* GUI-Action */

2023-11-06T14:10:06Z

GUI-Action

← Nächstältere Version		Version vom 6. November 2023, 14:10 Uhr
Zeile 139:		Zeile 139:
	==== GUI-Action ====		==== GUI-Action ====
	:a special type used with [[GUIBlock Element/en\|GUI blocks]].		:a special type used with [[GUIBlock Element/en\|GUI blocks]].
	:GUI elements (widgets) will get a notification whenever any value is written to such a variable.		:GUI elements (widgets) will get a notification whenever '''any''' value is written to such a variable.
	:In the GUI, these are defined as aspects (model or channel definitions)		:In the GUI, these are defined as aspects (model or channel definitions)

Cg: /* GUI-Value */

2023-11-06T14:09:49Z

GUI-Value

← Nächstältere Version		Version vom 6. November 2023, 14:09 Uhr
Zeile 134:		Zeile 134:
	==== GUI-Value ====		==== GUI-Value ====
	:a special type used with [[GUIBlock Element/en\|GUI blocks]].		:a special type used with [[GUIBlock Element/en\|GUI blocks]].
	:GUI elements (widgets) will get a notification whenever a new (different) value is written to such a variable.		:GUI elements (widgets) will get a notification whenever a new ('''different''') value is written to such a variable.
	:In the GUI, these are defined as aspects (model or channel definitions)		:In the GUI, these are defined as aspects (model or channel definitions)

Cg: /* Notes on "When First Used" initialization */

2023-11-06T14:06:18Z

Notes on "When First Used" initialization

← Nächstältere Version		Version vom 6. November 2023, 14:06 Uhr
Zeile 153:		Zeile 153:
	Variables flagged as such will open a request-dialog, when the variable's value is needed for the very first time by an action's input pin or by elementary code.		Variables flagged as such will open a request-dialog, when the variable's value is needed for the very first time by an action's input pin or by elementary code.
	This is in contrast to the "''request from user''" initialisation (above), which will always ask for the value at the beginning of a test run.		This is in contrast to the "''request from user''" initialisation (above), which will always ask for the value at the beginning of a test run.

			==== Notes on "GUI-Value" and "GUI-Action" initialization ====
			These will configure the variable to send out chagne notifications whenever a value (a '''different''' value for "GUI-Value" vs. '''any''' value for "GUI-Action") is written into the variable. Widgets will react on those notifications. Normal variables will not send out these notifications. Therefore, if a GUI widget is connected to a variable which is not of these 2 types (eg. "Constant"), then the widget will get no notification about changed values, and instead use the initial value only.

	== Toolbar Buttons ==		== Toolbar Buttons ==

Cg: /* GUI-Value */

2023-11-06T14:03:14Z

GUI-Value

← Nächstältere Version		Version vom 6. November 2023, 14:03 Uhr
Zeile 136:		Zeile 136:
	:GUI elements (widgets) will get a notification whenever a new (different) value is written to such a variable.		:GUI elements (widgets) will get a notification whenever a new (different) value is written to such a variable.
	:In the GUI, these are defined as aspects (model or channel definitions)		:In the GUI, these are defined as aspects (model or channel definitions)
	:If a GUI widget is connected to a variable which is not of this type (eg. "Constant"), then the widget will get no notification about changed values, but instead take the initial value only.

	==== GUI-Action ====		==== GUI-Action ====

Cg: /* GUI-Value */

2023-11-06T14:02:57Z

GUI-Value

← Nächstältere Version		Version vom 6. November 2023, 14:02 Uhr
Zeile 136:		Zeile 136:
	:GUI elements (widgets) will get a notification whenever a new (different) value is written to such a variable.		:GUI elements (widgets) will get a notification whenever a new (different) value is written to such a variable.
	:In the GUI, these are defined as aspects (model or channel definitions)		:In the GUI, these are defined as aspects (model or channel definitions)
			:If a GUI widget is connected to a variable which is not of this type (eg. "Constant"), then the widget will get no notification about changed values, but instead take the initial value only.

	==== GUI-Action ====		==== GUI-Action ====

Cg: /* Fields */

2023-03-16T11:08:27Z

Fields

← Nächstältere Version		Version vom 16. März 2023, 11:08 Uhr
Zeile 23:		Zeile 23:
	;R/W (read/write)		;R/W (read/write)
	:This field is a check box that determines whether the variable can be modified by the suite after initialization, or not. Parameter values should be set to read only, which is the default for new variables. If an action tries to modify a readonly variable, an exception will be raised.		:This field is a check box that determines whether the variable can be modified by the suite after initialization, or not. Parameter values should be set to read only, which is the default for new variables. If an action tries to modify a readonly variable, an exception will be raised.

			;S (static)
			:If checked, this will be a static variable, which is held in the step (not in the activity). Thus, the variable's value is preserved and seen when the step is executed again. Static variables can be used to implement counters or caches for expensive to construct data. Be aware, that the object held in the variable remains alife even after the execution of the action, and avoid introducing memory problems.

	;Datatype		;Datatype