GUI Editor-GUICode Editor/en
The UI-Editor provided by expecco is a modified variant of the Smalltalk/X UIPainter component. This is described in detail in "Using the UI-Painter. Notice that the UI-editor and GUI block elements are only included in the expecco PRO version.
The most notable difference is in the handling and representation of the models for the UI widget components. Where the Smalltalk version uses ValueHolders as provided by an application class, the expecco framework for GUI-Blocks uses adaptors. These adaptors look like regular value holders towards the widgets, but read and write pin data of the underlying step when accessed. Therefore, it is possible, to let an EditField or a Combobox operate on a pin's input- or output data.
Modal vs. Modeless GUI Blocks
So called "Elementary GUI blocks" are modal and pop up a dialog-interface when the activity is triggered, and close the window, when either an external close event arrives (at the close input pin) or via user interaction. The other form of GUI blocks are called "Compound GUI Blocks". These are modeless (i.e. they do not block execution) and are attached to a compound action block. These are completely controlled by the compound block's activity diagram, and can even show animations or real-time data.
Example: A Modal Forms Dialog
The following example demonstrates how a modal form-dialog using an elementary GUI block can be constructed. The goal is to present a textual list of choices, a radio-button list and a few other checkbox-choices in a modal box, for a user to make a choice and confirm.
Notice, that some of the input and output pins share a common name. This is only allowed for elementary UI blocks, and specifies that a pin value is used both to fill a value into a UI-component AND to be eventually read out of the UI component and sent to the blocks output pin (for example, to provide an initial value for an input field).
Next, navigate to the UI-tab, and click on the UI-editor icon. A standard UI-Painter will appear. Drag and drop the components as required into the UI canvas window, to get a look similar to:
Then, for each UI-widget component, select it, navigate to the "Basics" section, and change the name of the pin which provides/receives the widget's value. This can be done by typing the pin name into the input field named "model" or simply by pulling its menu, which shows a list of all pin names.
At the end, all model and list values have been specified, and the completed GUI looks like:
Notice that the listView component has two model aspect values: one which is to provide the list contents (the "list" aspect) and another, which holds the selected element (the "model" aspect).
Now, we are ready to place this block into an activity diagram:
Because these blocks are handled just like any other activity, you can of course provide input values from any other data source (freeze, environment, or another block). Also, the outputs (which provide the values of the fields, when the user clicks on "OK") are usually fed forward to other blocks for further processing. When executed, you get the following dialog to appear,
and the execution monitor shows the pin data as:
Where do I use this?
These Dialog-like elementary GUI blocks are very useful if the test suite needs additional parameters or values from an operator. For example, if there are some measurement values to be entered manually (because you do not have an interface, but need a human to read it). Such user interaction is especially useful in semi-automatic testing, where some manual testing/validation is to be integrated into an otherwise automatic test. A concrete example of our own past is a web-site checker, which asked the test-operator questions like "Please rate the overall design of the page" or similar.