Home » Archived » Test and Performance Tools Platform (TPTP) » record table items using automated gui recorder
| record table items using automated gui recorder [message #138285] |
Tue, 18 November 2008 11:59  |
 Asha
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
for recording and playback of the automated testcases for table content, i
got some inforamtion from the link
"https://bugs.eclipse.org/bugs/show_bug.cgi?id=133586" to record table
items .but how to do this..the macro generated after recording doesn't
contain any variable decalaration.here its written that
Here I have a proposal on how to do it safely.
1. Add a set of new attributes to the <command> element in the recorded XML
script, for storing the parent (Table) control information.
// Reference ID if Object Mine used
public static final String PARENT_REFERENCE_ID_ATTRIBUTE =
"parent-referenceId";
// If Object Mine not used, the Resolver ID
public static final String PARENT_RESOLVER_ATTRIBUTE = "parent-resolverId";
// If Object Mine not used, the Context ID
public static final String PARENT_CONTEXT_ID_ATTRIBUTE =
"parent-contextId";
// If Object Mine not used, the Widget ID
public static final String PARENT_WIDGET_ID_ATTRIBUTE = "parent-widgetId";
// The column and row of the parent Table.
public static final String PARENT_CELL_X_ATTRIBUTE = "parent-cell-x";
public static final String PARENT_CELL_Y_ATTRIBUTE = "parent-cell-y";
2. When recording, if current command is "modify" (for Text) or
"choice-select"
(for ComboBox), and search its parent can find a Table, then that means the
Control is a CellEditor in a Table. Then resolve the Table, and put the
resolved information into those "parent" attributes.
3. When playback, if these "parent" attributes exist in the <command>
element,
and it can be located and it's a Table, then send it an fake mouse event by
calculating out the center position of the cell, to activate the
CellEditor in
that cell, then continue with the "modify" or "choice-select" command.
Do you think this solution is acceptable? We are currently using this way
to
solve the in-cell editor of JFace Table and KTable. For JFace Table, it's
OK,
but for KTable, the bad thing is, after the modification, the AGR plugin
will
depends on KTable. If possible, I would also like to find a way to
"extend" the
core of AGR to support this kind of scenarios.
Jimmy Jin
can anyone tell me how to do that.
can any
|
|
|
| Re: record table items using automated gui recorder [message #138308 is a reply to message #138285] |
Tue, 18 November 2008 12:33  |
Paul Slauenwhite
Messages: 975
Registered: July 2009 |
Senior Member |
|
|
Hi Jimmy,
I believe your solution would work. However, we would have to code
review and test the implementation to be sure.
You can contribute this patch for the JFace tables by attaching it to
the bugzilla and answering the standard Eclipse Legal questions (see Figure
9 in http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf). For the
KTable, you will have to extend the AGR code and package it separately from
the AGR. Then you can contribute the code to SourceForge and we can link to
it on the TPTP web site.
Paul
"Asha " <asha@readiminds.com> wrote in message
news:0469fc05bececdad53a2b8f2157a8860$1@www.eclipse.org...
> for recording and playback of the automated testcases for table content, i
> got some inforamtion from the link
> "https://bugs.eclipse.org/bugs/show_bug.cgi?id=133586" to record table
> items .but how to do this..the macro generated after recording doesn't
> contain any variable decalaration.here its written that Here I have a
> proposal on how to do it safely.
>
> 1. Add a set of new attributes to the <command> element in the recorded
> XML
> script, for storing the parent (Table) control information.
>
> // Reference ID if Object Mine used
> public static final String PARENT_REFERENCE_ID_ATTRIBUTE =
> "parent-referenceId";
> // If Object Mine not used, the Resolver ID
> public static final String PARENT_RESOLVER_ATTRIBUTE =
> "parent-resolverId";
> // If Object Mine not used, the Context ID
> public static final String PARENT_CONTEXT_ID_ATTRIBUTE =
> "parent-contextId";
> // If Object Mine not used, the Widget I
> public static final String PARENT_WIDGET_ID_ATTRIBUTE = "parent-widgetId";
> // The column and row of the parent Table.
> public static final String PARENT_CELL_X_ATTRIBUTE = "parent-cell-x";
> public static final String PARENT_CELL_Y_ATTRIBUTE = "parent-cell-y";
>
> 2. When recording, if current command is "modify" (for Text) or
> "choice-select"
> (for ComboBox), and search its parent can find a Table, then that means
> the
> Control is a CellEditor in a Table. Then resolve the Table, and put the
> resolved information into those "parent" attributes.
>
> 3. When playback, if these "parent" attributes exist in the <command>
> element,
> and it can be located and it's a Table, then send it an fake mouse event
> by
> calculating out the center position of the cell, to activate the
> CellEditor in
> that cell, then continue with the "modify" or "choice-select" command.
>
> Do you think this solution is acceptable? We are currently using this way
> to
> solve the in-cell editor of JFace Table and KTable. For JFace Table, it's
> OK,
> but for KTable, the bad thing is, after the modification, the AGR plugin
> will
> depends on KTable. If possible, I would also like to find a way to
> "extend" the
> core of AGR to support this kind of scenarios.
>
> Jimmy Jin
>
> can anyone tell me how to do that.
>
> can any
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 13:30:02 GMT 2024
Powered by FUDForum. Page generated in 0.03344 seconds |
] 
Search
Help
Register
Login
Home
