· Mailing List
What It Records
The most difficult problem is to find the component for a recorded event in playback. Do we do this by the components name? By offset in the screen? Offset from its window? How do we even know which window the component is in?
Pounder stores a component event by an integer window id and a component identifier. Currently there are two types of component identifiers: name identifiers and layout identifiers. Name identifiers look through the children of a window and take the first one with the stored name. Layout identifiers recursively use the index of the child in its parent. For example: second child of third child of first child of window 32 ([1,3,2]).
As windows appear on the screen, a class WindowWatcher places them in a hashmap and gives them a unique id which is based on the order of their appearance (an integer incremented from 0). When events want to know what window a component is in, they ask a WindowWatcher. As long as windows appear in the same order during playback this will be fine.
Using component names as the default identification mechanism can be a problem. Few people name their components, and a name is not guaranteed to be unique. The solution I've adopted is to use a name if it exists, and in other cases generate a layout identifier.
Points are recorded using the percentage of size they represent in the component in which they occur. Take for example, a mouse click on JButton with size 100x100 at point (50,50). Pounder will record floating point pair (0.5, 0.5), and when it plays back this event it will use the JButtons current size to determine the point.
This was done because components get resized with different look and feels. Take for example a button that is 100x100 in one look and feel, and has a mouse click recorded at (100,0). Now if this event is moved to another platform where the button is size 80x40 it will fail in playback.
Scripts will be recorded and run on a variety of computers and operating systems. Because of this, it can be very hard to get the tests correctly synchronized. For example, a mouse event may be played on a window that has not yet been displayed. To help prevent these problems, Pounder will attempt to play failed events multiple times (exact amount can be changed by developers).
Here is a list of possible and known problems.
Copyright 2002 Matthew Pekar All rights reserved.