expecco Wiki (Version 25.x) - Letzte Änderungen [de]

Scheme Editor/en

Cg — Sat, 25 Apr 2026 11:15:01 GMT

Pin Specific Options (Context Menu)

← Nächstältere Version		Version vom 25. April 2026, 11:15 Uhr
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 13:		Zeile 13:
	== Pins ==		== Pins ==
	=== Adding & Removing [[DiagramElements-Pin\|Pins]] ===		=== Adding & Removing [[DiagramElements-Pin\|Pins]] ===
	New input and output pins can be added using the icon buttons in the top corners of each side of the action's representation box ([[Bild:Icon Add Inputpin.png]] / [[Bild:Icon Add Outputpin.png]]). Existing inputs and outputs can be removed using the icon buttons directly beside the buttons for adding ([[Bild:Icon Remove Pin.png]]), but a pin has to be selected for this operation first. Please note that some builtin blocks, like shell command blocks, have a fixed set of pins which can not be removed.		New input and output pins can be added using the icon buttons in the top corners of each side of the action's representation box ([[Bild:Icon Add Inputpin.png]] / [[Bild:Icon Add Outputpin.png]]).

			Existing pins can be removed using the icon buttons directly beside the buttons for adding ([[Bild:Icon Remove Pin.png]]), but a pin has to be selected for this operation first. The delete key can also be used (when a pin is selected).

			Please note that some builtin blocks, like shell command blocks, have a fixed set of pins which can not be removed.

	When new pins are added, they get default names attached with a sequential number, like ''in1'', ''in2'', ''out1'', ''out2'', etc.		When new pins are added, they get default names attached with a sequential number, like ''in1'', ''in2'', ''out1'', ''out2'', etc.
Zeile 40:		Zeile 44:
	In practice, the identifier should be a sequence of letters, digits or the underline character (_), where the very first character should not be a digit. It may also not be a keyword of the language (i.e. "<code>function</code>" in Groovy, "<code>if</code>" in JavaScript or "<code>self</code>" in Smalltalk).		In practice, the identifier should be a sequence of letters, digits or the underline character (_), where the very first character should not be a digit. It may also not be a keyword of the language (i.e. "<code>function</code>" in Groovy, "<code>if</code>" in JavaScript or "<code>self</code>" in Smalltalk).

	Such restrictions do not apply to compound blocks; ~~however~~, if you ever plan to convert or generate elementary code, it is a good idea to restrict your naming there too.		Such restrictions do not apply to compound blocks. However, if you ever plan to convert or generate elementary code, it is a good idea to restrict your naming there too.

	===== Restrictions on Pin Naming for JavaScript and Groovy Elementary Blocks =====		===== Restrictions on Pin Naming for JavaScript and Groovy Elementary Blocks =====
Zeile 64:		Zeile 68:

	=== Setup / Change Datatype ===		=== Setup / Change Datatype ===
	Each pin has a [[Datatype\|data type]] attribute that determines which kind of data is expected or generated by the pin. Every new pin initially gets the data type that was last used; initially the [[Datatype#General_Types\|data type "Any"]] is assigned by default. This type is also used as default, whenever no other reasonable data type can be predicted. The pin's data type is displayed beside the pin, outside of the representation box. The data type for a pin can be changed in the context menu, through its "''~~datatype~~''" sub-menu, which brings up a list of available types.		Each pin has a [[Datatype\|data type]] attribute that determines which kind of data is expected or generated by the pin. Every new pin initially gets the data type that was last used; initially the [[Datatype#General_Types\|data type "Any"]] is assigned by default. This type is also used as default, whenever no other reasonable data type can be predicted. The pin's data type is displayed beside the pin, outside of the representation box. The data type for a pin can be changed in the context menu, through its "''Datatype''" sub-menu, which brings up a list of available types.

	Note that when you have already placed [[DiagramElements-Step\|step]] instances of the modified action block in any activity diagram, a change in the data type of a pin may affect existing connections in which the pin is involved. If the new type is incompatible with a connection, it is drawn as dotted line in the diagram, or when a preset value becomes incompatible, the value is displayed in a red color.		Note that when you have already placed [[DiagramElements-Step\|step]] instances of the modified action block in any activity diagram, a change in the data type of a pin may affect existing connections in which the pin is involved. If the new type is incompatible with a connection, it is drawn as dotted line in the diagram, or when a preset value becomes incompatible, the value is displayed in a red color.
Zeile 88:		Zeile 92:
	:This option is used to specify the [[Datatype Element/en\|data type]] of the selected pin. This brings up a list of the available data types.		:This option is used to specify the [[Datatype Element/en\|data type]] of the selected pin. This brings up a list of the available data types.

	;~~Default~~ Value Editor		;Freeze Value Editor
	:This option allows you to specify the editor type for the freeze value, e.g. strings can be entered single line, multi-line or as a password string.		:This option allows you to specify the editor type for the freeze value, e.g. strings can be entered single line, multi-line or as a password string.

DiagramElements-FreezeValue/en

Cg — Sat, 25 Apr 2026 08:02:44 GMT

Bytes (ByteArray)

← Nächstältere Version		Version vom 25. April 2026, 08:02 Uhr
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 29:		Zeile 29:
	You can force single precision floats by using the 'f' exponent indicator.		You can force single precision floats by using the 'f' exponent indicator.

	* double precision floats such as: "<code>123.0</code>", "<code>+123.0</code>", "<code>-123.0</code>", "<code>.123</code>", "<code>123.</code>", "<code>123.0e+2</code>", "<code>123.0e-2</code>"		* double precision (64bit) floats such as: "<code>123.0</code>", "<code>+123.0</code>", "<code>-123.0</code>", "<code>.123</code>", "<code>123.</code>", "<code>123.0e+2</code>", "<code>123.0e-2</code>"

	* single precision: "<code>123.0f+2</code>" or "<code>-123.0f</code>"		* single precision (32 bit): "<code>123.0f+2</code>" or "<code>-123.0f</code>"

	* extended precision: "<code>123.0q+2</code>" or "<code>-123.0q</code>"		* extended precision (80+ bit): "<code>123.0q+2</code>" or "<code>-123.0q</code>"

			* quadruple precision (128 bit): "<code>123.0Q+2</code>" or "<code>-123.0Q</code>"

	Do not expect any speed or other advantages when using single precision floats. Actually, expect problems due to larger errors, non-stable series computations etc. Use them only if you need to emulate less precise computations.		Do not expect any speed or other advantages when using single precision floats. Actually, expect problems due to larger errors, non-stable series computations etc. Use them only if you need to emulate less precise computations.

	Extended precision floats may not be supported by all CPU types (these use the underlying machine's "long double" data type, which is either an 80-bit extended IEEE or a 128-bit quadruple IEEE float. As ~~not~~ all CPUs do support these, we ~~cannot~~ guarantee that future machines will ~~support them~~. However, currently all supported ~~machine~~ architectures do.		Extended precision floats may not be supported by all CPU types (these use the underlying machine's "long double" data type, which is either an 80-bit extended IEEE or a 128-bit quadruple IEEE float (eg. on Sparc CPUs). Not all CPUs do support these and we can not guarantee that future machines will dp. However, currently all supported architectures do.

			Notice that depending on the CPU, quadruple precision arithmetic might be performed by software and will therefore be slow (currently the case for all supported architectures)

	=== String ===		=== String ===
Zeile 63:		Zeile 67:
	In addition, variables of the form "<code>%(xxx)</code>" are expanded by the value of the input pin named "xxx". This expansion is also controlled by a flag in the popup menu.		In addition, variables of the form "<code>%(xxx)</code>" are expanded by the value of the input pin named "xxx". This expansion is also controlled by a flag in the popup menu.

	Freeze value expansion can be suppressed either in the ~~basket itself~~ (the freeze-menu),		Freeze value expansion can be suppressed either at the pin (see the freeze-menu),
	or globally via a flag in the project, to ~~enforce~~ ~~backward~~ ~~compatibility~~ of a ~~whole~~ ~~library~~ (in the rare situation, that an older library depends on such freeze values being unchanged).		or globally via a flag in the project or import library. Global disabling is discouraged and only to be used for backward compatibility (in the rare situation, that an older library depends on such freeze values being unchanged).

	Be reminded, that these variable expansions are only done for freeze values. If the value comes from another pin, it is passed unchanged.		Be reminded, that these variable expansions are only done for freeze values. If the value comes from another pin, it is passed unchanged.
Zeile 76:		Zeile 80:
	* hex format: "<code>xxXXxxXX</code>" (two hex characters per byte; no spaces in-between)		* hex format: "<code>xxXXxxXX</code>" (two hex characters per byte; no spaces in-between)
	* hex format: "<code>xx XX xx XX</code>" (two hex characters per byte; with spaces in-between)		* hex format: "<code>xx XX xx XX</code>" (two hex characters per byte; with spaces in-between)

			=== Arrays (Sequenceables) ===
			given that elements el1, el2, ... elN can be represented as literal constants (i.e. Strings, numbers, bytes or arrays), a sequence of them can be
			written as:
			* Smalltalk format: "<code>#( el1 el2 ... elN )</code> (with spaces between elements).
			* JSON format: "<code>[ el1 , el2 , ... , elN ]</code>

	=== Geometric Objects (Points and Rectangles) ===		=== Geometric Objects (Points and Rectangles) ===

VirtualBlock Element/en

Cg — Fri, 24 Apr 2026 17:44:48 GMT

When to Use

Environment Editor/en

Cg — Fri, 24 Apr 2026 17:19:08 GMT

Fields

← Nächstältere Version		Version vom 24. April 2026, 17:19 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
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)
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'')".

DiagramElements-FreezeValue/en

Cg — Fri, 24 Apr 2026 12:33:25 GMT

Introduction

← Nächstältere Version		Version vom 24. April 2026, 12:33 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 2:		Zeile 2:

	A so called "''Freeze Value''" is a constant value attached to an input pin.		A so called "''Freeze Value''" is a constant value attached to an input pin.
	When executed, that value will be presented to the action.		When executed, that value will be presented to the action. Pins with such a constant input are referred to as "''frozen pins''" in expecco.

			The freeze value can be either specified as a literal (textual) constant, or be provided by a variable (from an environment which is visible at the time the step is active).

	Be aware, that frozen pin values should normally not be consumed;		Be aware, that frozen pin values should normally not be consumed;
Zeile 10:		Zeile 12:
	Thus, the diagram editor will automatically change the pin's behavior to non-triggering and non-consuming (i.e. make it a "''parameter pin''").		Thus, the diagram editor will automatically change the pin's behavior to non-triggering and non-consuming (i.e. make it a "''parameter pin''").

	The following describes the data format and syntax used in pin freeze values.		The following describes the data format and syntax used for pin freeze values.
	In general, the text entered as freeze value is parsed by the input pin's datatype.		In general, the text entered as freeze value is parsed by the input pin's datatype, or if it is provided by a variable, that variable's data type.

	== Format for Particular Types ==		== Format for Particular Types ==

Java Interface Library/en

Cg — Fri, 24 Apr 2026 10:47:54 GMT

Architecture

← Nächstältere Version		Version vom 24. April 2026, 10:47 Uhr
Zeile 26:		Zeile 26:


	+---------------------+ +~~---~~-------+ +----------------+ +~~---~~-------------+ +---------+		+-------------------+ +-------+ +----------------+ +-------------+ +--------+
	\| \| \| \| \| \| \| \| \| Java \|		\| \| \| \| \| \| \| \| \| Java \|
	\| expecco \|---->\| Proxy \|---->\| Bridge \|==>>==\| Bridge \|---->\| Object \|		\| expecco \|--->\| Proxy \|--->\| Bridge \|==>>==\| Bridge \|--->\| Object \|
	\| (elementary code) \|<----\| \|<----\| (expecco side) \|==<<==\| (Java side) \|<----\| \|		\| (elementary code) \|<---\| \|<---\| (expecco side) \|==<<==\| (Java side) \|<---\| \|
	+---------------------+ +~~---~~-------+ +----------------+ +~~---~~-------------+ +---------+		+-------------------+ +-------+ +----------------+ +-------------+ +--------+


Zeile 42:		Zeile 42:

	Notice that a similar mechanism is used in expecco to communicate with DOTNET, Qt (C++) and C applications.		Notice that a similar mechanism is used in expecco to communicate with DOTNET, Qt (C++) and C applications.


	== Initializing / Releasing the Bridge ==		== Initializing / Releasing the Bridge ==

WindowsAutomation Reference 2.0/en

Mb — Tue, 21 Apr 2026 09:32:56 GMT

Cant't find elements using AutomationId

← Nächstältere Version		Version vom 21. April 2026, 09:32 Uhr
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 386:		Zeile 386:
	In some cases - e.g. starting the test via Jenkins - the application (SUT) is not in the correct state after startup. You can't find elements and/or actions fail.		In some cases - e.g. starting the test via Jenkins - the application (SUT) is not in the correct state after startup. You can't find elements and/or actions fail.
	You can try to send "[WA]Window - Normalize" with the path of the window to solve this		You can try to send "[WA]Window - Normalize" with the path of the window to solve this

			== Cannot find elements using AutomationId ==

			There are several cases why your AutomationId is not unique/stable inside the application (SUT):

			::- Dynamic genarated Ids (e.g. Datagrids, Lists)
			::- Reused Controls in different windows
			::- Changed Ids depending on SUT version or state

Installing additional Frameworks/en

Cg — Tue, 21 Apr 2026 06:32:56 GMT

GNU Octave Installation (Matlab compatible Scripting)

← Nächstältere Version		Version vom 21. April 2026, 06:32 Uhr
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 283:		Zeile 283:
	# load the suite on a Linux machine (with C-compiler toolchain available)		# load the suite on a Linux machine (with C-compiler toolchain available)
	# ensure that the "''Store Object Files''" flag is checked.		# ensure that the "''Store Object Files''" flag is checked.
			# run the suite
	# Save the suite		# Save the suite
	# load the saved ".ets" on a Windows machine (with C-toolchain available)		# load the saved ".ets" on a Windows machine (with C-toolchain available)
			# run the suite
	# Save it again.		# Save it again.
	The last saved ".ets" will now contain object files for both architectures.		The last saved ".ets" will now contain object files for both architectures.
Zeile 290:		Zeile 292:

	Be reminded that this procedure is not needed, if the machine which executes the tests does have a C-toolchain installed. And especially, if it is the same as your development machine.		Be reminded that this procedure is not needed, if the machine which executes the tests does have a C-toolchain installed. And especially, if it is the same as your development machine.

			==== See Also ====
			For more information see "[[Cbridge_setup\| CBridge Setup]]" and for
			command line arguments to the cBridge, take a look at "[[Cbridge_setup#CBridge_Command_Line_Arguments\| CBridge Command Line Arguments]]".

	== <div id="Cling_Installation">Cling Installation</div> (for RootCling Actions) ==		== <div id="Cling_Installation">Cling Installation</div> (for RootCling Actions) ==
Zeile 371:		Zeile 377:
	== <div id="GNU_Octave_Installation">GNU Octave Installation</div> (Matlab compatible Scripting) ==		== <div id="GNU_Octave_Installation">GNU Octave Installation</div> (Matlab compatible Scripting) ==

		⚫	Download: https://octave.org/download
	;OS X (Mac):
		⚫	<br>OpenSuse users can "<code>zypper install octave</code>".
	: Download a dmg from
	:  https://wiki.octave.org/Octave_for_macOS
	: or:
⚫	: ~~ ~~https://octave~~-app~~.org
	: or:
⚫	: <code>~~sudo port~~ install octave</code>

	;Windows:
	:Download from https://www.gnu.org/software/octave/download.

	Warning: octave is huge (roughly 1Gb download).		Warning: octave is huge (roughly 1Gb download).

Cbridge setup

Cg — Mon, 20 Apr 2026 08:14:30 GMT

Remote C-Bridges

@@ Zeile 66: / Zeile 66: @@
 = Remote C-Bridges =
-You can run any number of cBridges on any machine within your network, and execute C-actions there. For this, the following setup steps are to be performed:
+You can run any number of cBridges on any machine within your network (and also multiple cBridges on your local or a remote machine), and execute C-actions there. For this, the following setup steps are to be performed:
 * copy the cbridge executable and its support files to a new folder on the target machine; the files are found below the expecco installation folder<br>(eg. "<code>c:\Program Files\exept\expecco</code>") in "<code>packages\bridgeFramework\cBridge\cLibrary</code>".
@@ Zeile 75: / Zeile 75: @@
 * if in doubt, start the cBridge with a "<code>--help</code>" option.
 === SSL Connection to the Remote CBridge ===

← Nächstältere Version		Version vom 24. April 2026, 17:44 Uhr
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 4:		Zeile 4:
	It can be placed into a network like any other block.		It can be placed into a network like any other block.

			==How Does it Work==
	During the execution, [[DiagramElements-Step\|steps]] ~~for~~ virtual ~~actions~~ will determine the real action to be performed ~~dynamically, at execution time~~.		During the execution, [[DiagramElements-Step\|steps]] a virtual action's step will dynamically determine the real action to be performed.
	This is done via one of two mechanisms:		This is done via one of two mechanisms:

	==== Explicit, Direct Performer: ====		=== Explicit, Direct Performer: ===

	If the [[DiagramElements-Pin#Performer Input Pin\|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's ID specified as its interface.		If the [[DiagramElements-Pin#Performer Input Pin\|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's function ID (fID) specified as its interface.<br>
	The reference can be provided by another step (dynamically computed), via the environment using an [[DiagramElements-Environment Freeze Value\|environment-freeze value]] or directly as a freeze value. Of course, ~~any~~ environment ~~variables~~ must have been initialized elsewhere before.		The reference can be provided by another step (dynamically computed), via the environment using an [[DiagramElements-Environment Freeze Value\|environment-freeze value]] or directly as a freeze value. Of course, the environment variable must have been initialized elsewhere before.

		⚫	The reference's value can be defined either as an action's fID, or its name. For convenience, actions can be directly dragged from the tree and dropped onto a performer input pin. Obviously, using a constant freeze value as performer-pin input makes the whole virtual mechanism useless, as you could then just place the concrete action. So this is usually only done for testing and demonstration purpose.

⚫	The reference's value can be defined either as ~~the~~ action's ID, or its name. For convenience, actions can be directly dragged from the tree and dropped onto a performer input pin. Obviously, using a constant freeze value as performer-pin input makes the whole virtual mechanism useless, as you could then just place the concrete action. So this is usually only done for testing and demonstration purpose.
	In real-world scenarios, the reference is almost always provided by an environment variable, as described below.		In real-world scenarios, the reference is almost always provided by an environment variable, as described below.

	==== Implicit Performer via a mapping in the Environment: ====		=== Implicit Performer via a mapping in the Environment: ===

	If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[Virtual Library\|virtual library]].		If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[Virtual Library\|virtual library]].

	===== Individual Action Mapping: =====		====== Individual Action Mapping: ======

	For this, the environment should contain a mapping from virtual-action-id to concrete action-id. I.e. it must contain a slot where a reference to the virtual action is key, and a reference to the concrete action is the value.		For this, the environment should contain a mapping from virtual-action-id to concrete action-id. I.e. it must contain a slot where a reference to the virtual action is key, and a reference to the concrete action is the value.
	Such mappings cannot be created via the environment editor (as it only creates slots with a string-type namekey), instead, a special block is provided, which creates such a mapping in its surrounding environment.		Such mappings cannot be created via the environment editor (as it only creates slots with a string-type namekey), instead, a special block is provided, which creates such a mapping in its surrounding environment.

	===== Virtual Library Mapping: =====		====== Virtual Library Mapping: ======

	The most convenient way to specify virtual actions is by providing a virtual- to concrete library mapping. For that, a special block is provided, which expects a reference to a virtual library and a reference to a concrete library as inputs. After that mapping has been created, any reference to any virtual block of that library will be resolved using a corresponding concrete block from the concrete library.		The most convenient way to specify virtual actions is by providing a virtual- to concrete library mapping. For that, a special block is provided, which expects a reference to a virtual library and a reference to a concrete library as inputs. After that mapping has been created, any reference to any virtual block of that library will be resolved using a corresponding concrete block from the concrete library.