GUI Capture (Developement) - Revision history

Manus: Added category

2007-05-30T18:30:51Z

Added category

Juliant at 00:59, 4 November 2006

2006-11-04T00:59:26Z

Manus at 16:28, 1 November 2006

2006-11-01T16:28:33Z

Juliant at 01:37, 1 November 2006

2006-11-01T01:37:20Z

Manus: fixed typo

2006-11-01T00:51:26Z

fixed typo

Juliant: /* Output Formats */

2006-11-01T00:32:21Z

‎Output Formats

Juliant: /* Output Formats */

2006-11-01T00:31:15Z

‎Output Formats

Juliant at 00:30, 1 November 2006

2006-11-01T00:30:53Z

Juliant at 00:12, 1 November 2006

2006-11-01T00:12:14Z

Juliant at 00:10, 1 November 2006

2006-11-01T00:10:30Z

← Older revision		Revision as of 18:30, 30 May 2007
Line 1:		Line 1:
		+	[[Category:Testing]]
	{{cleanup}}		{{cleanup}}
	==Overall structure==		==Overall structure==

← Older revision		Revision as of 00:59, 4 November 2006
Line 1:		Line 1:
−	~~[[Category:Testing]]~~	+	{{cleanup}}
	==Overall structure==		==Overall structure==

← Older revision		Revision as of 16:28, 1 November 2006
Line 1:		Line 1:
		+	[[Category:Testing]]
	==Overall structure==		==Overall structure==

@@ Line 1: / Line 1: @@
 ==Overall structure==
 [[Image:Gui_capture_overall_structure.png]]
 ===Platform independence===
 ==Capture Engine==
 The engine has the tasks:
@@ Line 16: / Line 19: @@
 * send the events to the output handler
 * (filter events?)
 ==Event Hierarchy==
 [[Image:Gui_capture_event_hierarchy.png]]
 To allow different output formats, the events types are equipped 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 happened 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.
@@ Line 42: / Line 47: @@
 ===Event Hook===
 To get the events from another window, a hook can be installed. The hook is installed through a custom DLL. All messages which are sent to the window are then stored by the dll and can be polled by the capturing application.
@@ Line 55: / Line 57: @@
 How to get the widget name for an event is not yet clear. Since the name is only known in Vision2 the capturing application has to somehow call a feature on the window. This could probably be done by sending a special message to the window (through the windows message queue) which is then catched by Vision2. The name is then sent back by sending a message back through the windows message queue to the capturing application.
 '''Problem: other events can be processed in the meantime. The ordering of the events could be problematic'''
 ===Native Functionality===
 needed functions:
@@ Line 69: / Line 73: @@
 * request_widget_name (x, y): STRING
 *: send a request to the window for the widget name
 ==Unix Implementation==
 Not yet started
 * Eiffel Code

@@ Line 23: / Line 23: @@
 [[Image:Gui_capture_event_hierarchy.png]]
-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.
+To allow different output formats, the events types are equipped 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 event has to store the necessary data to replay it (raw data) but should also store additional information like the widget it happened 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.
@@ Line 62: / Line 62: @@
 *: install hook into process identified by 'process_id'
 * stop_capturing
-*: unisntall hook
+*: uninstall hook
 * has_event
 *: check event queue in custom DLL
@@ Line 82: / Line 82: @@
 * Eiffel Code
-*: Generate an eiffel class to replay the event sequence. It should be easy to insert assertions into the code to create a testcase. Until the problems in the replaying phase are solved, the testcase has to be compiled together with the application, so the output formatter should be aware of that.
+*: Generate an Eiffel class to replay the event sequence. It should be easy to insert assertions into the code to create a testcase. Until the problems in the replaying phase are solved, the testcase has to be compiled together with the application, so the output formatter should be aware of that.
 * XML Data
 *: An XML output could be used to create a ''Bug Report'' from a customer and replay it on a player.

← Older revision		Revision as of 00:12, 1 November 2006
Line 5:		Line 5:
	===Platform independence===		===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.	+	For the output to remain independent from the platform, 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.

@@ Line 6: / Line 6: @@
 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.
@@ Line 30: / Line 40: @@
 * Key Code
 * Key state change