What It Records

• Mouse motion, drag, click, and wheel events
• Window events (resize, maximize, movement, etc.)
• Key events

What Component?

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.

Recording Points

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.

Synchronization

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).

Problems

Here is a list of possible and known problems.

• Points may not recorded precisely. There may be a rounding issue.
• Mouse motion related events do not always playback correctly. For example, a mouse drag for a menu selection may be played back too quickly to catch, and the menu may not show.
• Popup menu events are not cross-platform (working on this).
• Hotkeys are not cross-platform.
• I haven't confirmed this myself, but I think the save/load dialogs differ by platform. Pounder will likely choke if they do (unless the designers happened to use a common naming scheme).
• AWT components are poorly supported, mostly because of their naming scheme. Each new component gets a new name, so Pounder gets confused. Also, menus are not Component's, so I have no decent way of recording their events. Don't expect good AWT support any time in the near future.

Many thanks to SourceForge for hosting this project.

Copyright 2002 Matthew Pekar  All rights reserved.