viewer
Desktop Viewer
The Desktop Viewer is the GUI component situated at the right side of the T-Plan Robot Enterprise GUI.
- When there's no desktop connection it shows the interactive T-Plan Workflow chart which covers the QA and automation life cycle with the T-Plan product line.
- When a remote desktop is connected the viewer displays its image and allows to drive it through the mouse and keyboard.
The GUI by default creates a tabbed view for the workflow and the desktop. To disable this behaviour and make the viewer display just the desktop image set off the Display Workflow When Connected option in the Desktop menu. Since version 4.0 the desktop viewer may operate in a separate window (so called detached mode). To set it on or off use the Desktop->Detach Desktop Viewer menu item.
The connected remote desktop serves as the System Under Automation (SUA). The word of "remote" means that it is typically other desktop than the local one. The desktop capabilities depend on the selected connection protocol (type). See the Release Notes document for the list of supported connections and the SUT set up instructions. A connection to a desktop can be established in several ways:
- Automatic connection using CLI connect options such as c/connect, -p/password and -u/-user. See the CLI Options Specification.
- Manual connection through the Login Window either at the start up or later through the Connect tool bar button or the Desktop->Connect Desktop menu item.
- Programmatic connection through execution of a Connect command or its corresponding Java Script API method from an automated testing script.
To disconnect from a desktop click the Disconnect tool bar button or the Desktop->Disconnect Desktop menu item. You can also disconnect by execution of a Disconnect command. As the viewer can handle just one desktop connection at a time (no tabbed views) connecting to another desktop will disconnect the previous connection. Execution of multiple parallel automated testing processes is typically achieved through the CLI mode (with no GUI displayed).
The viewer is also able to operate in the read-only mode when no user input is transferred to the remote desktop. To switch this mode on or off use the 
Desktop->Read Only menu item. It is useful when more users share the same desktop or when you want just to view the desktop without interacting with it.
The read only mode may be also toggled through the Ctrl+F10 shortcut key (configurable in the Desktop Viewer panel of the Preferences window). This works even if the desktop is active and the key is filtered out from the communication between Robot and the desktop server. This is handy when one needs to take a screenshot of or create a template image from a desktop which displays an application driven by mouse moves, such as for example the Windows Start menu. The short cut key in this case toggles on the read only mode and stops the viewer immediately from sending the mouse events to the server. The viewer automatically switches to read-only mode when a script execution is started to prevent users from unintentional interference with the environment. This behaviour is configurable in the Desktop Viewer panel of the Preferences window. It works as follows:
- When a script gets executed and the read-only mode is already on, the feature does nothing and it doesn't reset the mode when the script finishes. The point is to preserve the mode before the execution and respect the user manual setting.
- When the read-only mode is off when a script gets started, the mode is set on when execution starts and it is set off when the script finishes.
The viewer plays an important role in the main GUI. It allows to interact visually with the remote system in order to record and design scripts or to watch progress of an automated testing process. Script Recorder and Script Editor are other two major GUI components which cooperate closely with the viewer to produce automated testing scripts.
The Script Recorder is able to attach to the viewer's input event queue and record user interaction into the active script editor. The Script Editor then allows to execute the script or its part on the connected desktop. The underlying connection framework provides several mechanisms useful mechanisms configurable through the Desktop->Desktop Preferences menu item:
Feature | Description |
|---|---|
Refresh Daemon | The Refresh Daemon is a background process which keeps the desktop session alive. If you don't move your mouse or type a key for a long time, the remote server usually runs a screen saver or locks up the desktop. Some desktop servers are also known to close the connection after a period of idle time. The daemon simply moves your mouse back and forth by one or two pixels after the configured idle time (5 minutes by default) to prevent these situations. The daemon doesn't run while a script is being executed. This is intended to prevent unwanted interference into the script execution. There's a flag in the preferences allowing to change this behavior and run the daemon even during automation. |
Connection Recovery | The Connection Recovery mechanism repairs broken desktop connections during script executions. The framework automatically puts on hold any I/O operations (mouse, keyboard) and makes a few attempts to reconnect to the desktop until the specified time expires. If the connection gets recovered successfully the script resumes execution. This mechanism targets recoverable connection errors such as for example intermittent network outages. It won't help if the target server crashes and it does not get restarted automatically by the SUT. The recovery feature is by default off and must be enabled through the Desktop Preferences prior to the script execution. |
Connection Pooling | The Connection Pooling mechanism allows the executed scripts to release the desktop connection to the pool after the use rather than destroying them (disconnecting). Such connections may be then picked up by other scripts. This approach avoids the overhead of the desktop connection and it may significantly improve performance (while increasing the memory requirements) of multi threaded automated testing applications, especially where multiple shorter scripts are executed against just one or a few environments. Operation of the connection pool requires a license with at least 2 connections (seats). For details see the RemoteDesktopClientFactory class documentation. To find out how many seats your instance is licensed to see the Tool->License Key Manager window. |