Difference between revisions of "GUI Capture (Developement)"
Line 19: | Line 19: | ||
The widget which was accessed has to be accessed through Vision2 which poses some problems for the capturing process on how to communicate with the Vision2 application. | The widget which was accessed has to be accessed through Vision2 which poses some problems for the capturing process on how to communicate with the Vision2 application. | ||
− | + | All Events: | |
− | + | * Vision2 widget name (if applicable) | |
− | + | All Mouse Events: | |
− | + | * x, y coordinate | |
− | + | Mouse Click Event: | |
− | + | * Button state change | |
− | + | All Keyboard Events: | |
− | + | * Key Code | |
− | + | * Key state change |
Revision as of 14:24, 31 October 2006
Overall structure
Platform independence
For the output to remain platform independent from the input, the engine passes the events in a uniform format to the output which can use the process_xy_event features inherited from the CAPTURE_EVENT_VISITOR class to generate the output. The input is generated by the engine implementation which is specific for the platform used.
Event Hierarchy
To allow different output formats, the events types are equiped with a process feature which implements the visitor pattern together with the CAPTURE_EVENT_VISITOR class.
Event Data
The event has to store the necessary data to replay it (raw data) but should also store additional information like the widget it happend on. This could be done by giving all widgets (or just the important ones) a name and storing that name along with the event data.
The widget which was accessed has to be accessed through Vision2 which poses some problems for the capturing process on how to communicate with the Vision2 application.
All Events:
- Vision2 widget name (if applicable)
All Mouse Events:
- x, y coordinate
Mouse Click Event:
- Button state change
All Keyboard Events:
- Key Code
- Key state change