Home | About Us | Products | Sales | Demos | Links | Support | Contact Us

SUPPORT

Search Support
VSP Support
Vermont HighTest Plus
FAQ
Free Upgrades
Downloads
Get License Keys
License Management
HighTest Blog
Discussion Forum
Vermont Views
Technotes
Discussion Forum
Downloads
2.04
2.05
3.0
3.05
4.0
4.05
Termcaps
Help Files
Vermont Views for Windows
Technotes
Updates
Views Utility Programs
Vermont Test
Year 2000

HighTest Plus 3.05+ FAQ
(Updated July 7, 2000)

Question:
Why can ClickScrollVert() and ClickScrollHorz() commands report success even when they fail?

Answer:
There are cases when the log file shows that a ClickScrollVert() or ClickScrollHorz() command succeeded, but in fact it failed. This apparent contradiation can happen in the following case:

The scrollbar is on a ComboBox LBox window and the combobox was not dropped down. Since it was not dropped down, the click on the scroll bars will not happen correctly. We have seen a case where the ActivateWindow() on the combobox failed due to a dynamic ID. After that failure, all bets are off. HighTest then continued and searched for a ComboLBox with the given ID and class. It found one and played back to it. But, this ComboLBox is not visible, so when HighTest plays back to it, nothing happens on the screen.

And because HighTest did find a ComboLBox with scroll bars, and played back to it, it reported SUCCESS in the log file, which in fact is true.

Question:
Why does HighTest Plus sometimes take a screenshot of the entire screen when I had specified a specific window?

Answer:
This is HighTest's way of telling you that the window that it was looking for was unable to be found. Rather than not grab any window, HighTest takes a full screenshot and puts it into its database. This way, a failure is sure to be generated and alert you to the fact that something is wrong.

Question:
How can I get HighTest Plus 3.0 to successfully play back a script? It seems to fail each time I play it back.

Answer:
There are many factors that affect a successful playback of a script. Many of them require some detailed knowledge of your application and a basic understanding of the design and structure of a Windows program. Once you have a good knowledge of these areas, it is usually very easy to tailor HighTest so that scripts will play back accurately and successfully.

The items that one must know about their application include the following:

• Was the application designed using controls (what are those anyway) or painted objects?
• Does the application use static or dynamic IDs for each control?
• Does the application use static or dynamic classnames (and what are they) for each control?
• How long does it take for each screen (especially the startup screen) to come up?

Question:
What are the STATE values in the WaitWindow() command and how do I use them?

Answer:
Unfortunately the manual is not clear on how to use these values and the way it combines them makes it unclear when you would use a particular value.

The first thing to realize is that this command deals with many kinds of windows. Usually, they fall into the dialog type window where there are many controls and fields on them. But, each control on a dialog also has a window, and WaitWindow() is also designed to work with the various types of buttons that you will find on dialogs such as pushbuttons, radio buttons and checkboxes.

For standard type of windows, you can determine whether or not the window is visible or if it has been closed. Use values for standard windows as follows:

0 - Window not visible
4 — Window Visible
7 — Window Closed — exact title match
8 — Window Closed — partial title match

These are the only values to use for windows. Do not try to use the other values for windows.

Buttons are a special type of window that have properties that can be set programatically or dynamically by the user. HighTest can query the window to find the state of the window as either checked, unchecked or indeterminate. Use values for buttons and checkboxes as follows:

0 — Not visible and not checked
1 — Not visible and checked
2 — Not visible and has indeterminate state (for tri-state buttons)
4 — Visible and not checked
5 — Visible and checked
6 — Visible and indeterminate state (for tri-state buttons)

Question:
How can I get HighTest to run a Control Panel Applet?

Answer:
This is not as simple as simply finding the executable and then running it with StartApp() as these are not full-fledged programs, rather they are Dynamic Link Libraries (DLLs) that you can't execute directly. The solution to this problem is to use the StartApp() command as follows:

Startapp("rundll32.exe shell32.dll,Control_RunDLL timedate.cpl", NORMAL) Note that in this example, we are running the Time & Date utility, but you can replace it with any other applet. They can be found in the \windows\system or \winnt\system32 directory with the .cpl extension.

Question:
How can I test Web-based applications or sites?

Answer:
HighTest through version 4.10, does not recognize the browser as a separate entity and does not recognize browser-based controls that are standard parts of html pages. In addition, HighTest cannot tell when a page is done loading as the browser does not have a window open or close that HighTest can use to properly synchronize with the application. There are techniques and workarounds that you can employ to enable HighTest to work reasonably well with browser-based applications and many people are using these techniques successfully. For more information, you can download a zip file with sample scripts for version 3.5 and below and version 4.0 and above. Note that new features in version 4.0 make this process much quicker and easier than in previous versions.

Download web browser samples for HighTest 3.50 and below or for HighTest 4.0 and above.