Understand SystemUtil.Run, SetSecure, Set, Type: QTP/UFT
Thomas Hamilton
⚡ Smart Summary
SystemUtil.Run is the UFT One command that launches a file or an application at the start of a run session, while Set, SetSecure and Type feed values and keystrokes into the window it opens.
SystemUtil.Run in UFT
Every recorded GUI test needs a first step that brings the application under test on screen. In OpenText Functional Testing (UFT One, formerly Micro Focus UFT and originally HP QTP), that step is SystemUtil.Run. Let’s understand the following piece of code
SystemUtil.Run "C:\Program Files\HP\samples\flight\app\flight.exe" Dialog("Login").WinEdit("Agent Name:").Set "Guru" Dialog("Login").WinEdit("Agent Name:").Type micTab Dialog("Login").WinEdit("Password:").SetSecure "4af272a62666d2e" Dialog("Login").WinButton("OK").Click Window("Flight Reservation").Close
- The first step is the SystemUtil.Run Command which is used by default by UFT/QTP to open an application. During recording, using the Windows Start Menu, we navigated to the “Flight Reservation” application. At that time, Micro Focus UFT identified the location of its executable file and inserted the SystemUtil.Run Command to Open it.
- Line 2 is Setting Agent Name as Guru as shown in the Active Screen
- Line 3 is Pressing the Tab key on a keyboard to bring Focus from Agent Name Field To Password Field, which is exactly this step. Human users need to use tab or click operations to focus on a particular object on screen. On the other hand, Quick Test can directly identify an object using object properties and does not require these “maneuvering” operations. We can delete this step, as UFT One will still be able to set the password field without this operation
- Line 4 is Setting the Password as Mercury. UFT One automatically encrypts passwords entered while recording to avoid security breaches. This value cannot be decrypted i.e. there is no way to recover the original value using this cryptic data. You can explicitly encrypt a password using the Password Encoder Tool. For our learning purposes, we will use the password in its raw form. And the operation will also change to Set
- Line 5 is clicking the okay button
- Line 6 is closing the window
⚠️ Version note: the recorded path above points at the old C:\Program Files\HP\samples\flight location used by HP QTP. The sample Flight Reservation application still ships with UFT One, but under the current installation folder, so the literal path in a script recorded today will differ.
Click here if the video is not accessible
SystemUtil.Run Syntax and Arguments
The recorded line above uses only the first argument, but the method accepts five. Knowing all of them turns SystemUtil.Run from a recorder artefact into a deliberate launch step you can write by hand.
SystemUtil.Run file, [params], [dir], [op], [mode]
| Argument | Required? | What it does |
| file | Required | Name of the file or application to run. A non-executable file opens in its associated application. |
| params | Optional | Parameters passed to the application when file is an executable. Default is an empty string. |
| dir | Optional | Default directory for the application or file. Default is an empty string. |
| op | Optional | Action to perform: open, edit, explore, find or print. A blank value performs open. |
| mode | Optional | Integer that controls how the window is displayed when it opens. Default is 1. |
The op argument is the one most testers never discover. It maps onto the same verbs Windows Explorer offers on a right-click.
| op value | Result |
| open | Opens the file, folder or executable named in file. |
| edit | Launches an editor and opens the document for editing. Fails if the file is not an editable document. |
| explore | Explores the folder named in file. |
| find | Starts a search from the specified folder path. |
| Prints the document named in file. Fails if the file is not printable. |
For mode, the values that matter day to day are 0 (hide the window and activate another), 1 (activate and display at its original size), 2 (activate minimized) and 3 (activate maximized). Higher values control focus and restore behaviour and are rarely needed in a test.
SystemUtil.Run Examples: Applications, Browsers and Files
The examples below build up one argument at a time, so you can see what each position adds. Paste them into a new action and run them one line at a time.
1) file only — the shortest useful form. An executable on the system path needs no folder, and a document opens in whatever application Windows has registered for it.
SystemUtil.Run "notepad.exe" SystemUtil.Run "C:\Data\Orders.txt"
2) file plus params — anything the application would accept on a command line goes here. This is how a browser is opened on a specific address rather than its home page.
SystemUtil.Run "notepad.exe", "C:\Data\Orders.txt"
3) adding dir — useful when an application refuses to start unless its own folder is the working directory.
SystemUtil.Run "flight.exe", "", "C:\Program Files\HP\samples\flight\app\"
4) adding op — the same file, four different outcomes.
SystemUtil.Run "C:\Data\Orders.txt", "", "", "edit" SystemUtil.Run "C:\Data", "", "", "explore" SystemUtil.Run "C:\Data", "", "", "find" SystemUtil.Run "C:\Data\Orders.txt", "", "", "print"
5) adding mode — open the window maximized so later steps are not blocked by a partly hidden control.
SystemUtil.Run "notepad.exe", "C:\Data\Orders.txt", "", "open", 3
Because the launched window becomes an ordinary test object, the very next line can drive it. The official documentation pairs Run with Type and Close in exactly this way.
SystemUtil.Run "C:\type.txt", "", "", "" Window("Text:=type.txt - Notepad").Type "happy days" Window("Text:=type.txt - Notepad").Close
Notice the descriptive Text:= form in that snippet: no repository entry is needed. The same idea is covered at length in descriptive programming, and hard-coded paths like the ones above are usually better held in environment variables so one script runs on every machine.
Set, SetSecure and Type: Which Method to Use
Lines 2 to 4 of the recorded script use three different methods on the same kind of edit field. They are not interchangeable, and picking the wrong one is a common cause of a step that passes silently without entering anything.
| Method | What it sends | Use it when |
| Set | Writes a plain-text value directly into the field. | Normal data entry, including a password you are happy to keep readable. |
| SetSecure | Writes an encoded string that UFT One decodes at run time. | Any password field, so the value never appears in the script or the results. |
| Type | Sends raw keystrokes, including keys such as micTab. | Keyboard behaviour is part of the test, or a control only reacts to real keys. |
As the walkthrough notes, the Tab keystroke on line 3 exists only because the recorder captured a human habit. UFT One identifies the password field by its properties, so deleting that line changes nothing. Swap SetSecure for Set and the same login runs with a readable password.
Dialog("Login").WinEdit("Password:").Set "mercury"
To go the other way and encode a value outside a recording session, use the Password Encoder. The GUI tool ships with UFT One, and the same encoding is available from a command line as CryptonCMD.exe -e in the product bin folder. Both produce strings you can drop into a SetSecure argument or into a data table parameter. The vendor is explicit that this encoding is not a security standard: it hides a value on screen, it does not protect real customer data.
Once these three methods are second nature, the rest of the language follows quickly — the VBScript basics and the wider UFT One tutorial series cover loops, conditions and reusable functions, while Object Spy and GetROProperty show you which properties UFT One is actually matching on.
