Bugzilla – Full Text Bug Listing
| Summary: | Support editing table items | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | amehrega |
| Component: | TPTP | Assignee: | Paul Slauenwhite <paulslau> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | elias, jimmyjin.jxm, nedelec, paulslau |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | closed471 | ||
| Bug Depends on: | |||
| Bug Blocks: | 170651 | ||
|
Description
amehrega
Planning to defer to post 4.3 Deferring to 4.4 according to Paul’s recent e-mail. Updating original estimate based information provided by Liz. Targeting to future since cannot be contained in 4.4. Targeting to future since cannot be contained in 4.4. As discussed on this week's Test Project call (January 22, 2007), the Test Project will focus on existing P1 - P2/Blocker - Major and P1/Normal and test creation/automation defects (omitting defects dependant on outstanding features) in TPTP 4.4. All other Test Project defects have been targeted to future. If this defect has been targeted to future and you/originator feel it should be completed in 4.4, please provide the necessary reason as a reply to this comment or a post to the Test Project mailing list (tptp-test-tooling-dev@eclipse.org). We will collectively triage and assess our resources to determine a case-by-case decision. Correction: The Test Project mailing list is tptp-testing-tools-dev@eclipse.org. This defect blocks a Test Project test suite (see 170651). As such, increaseing the severity. We will need this defect fixed in 4.5 since it is blocking 170651. Reassigning to Project Lead until new Component Lead is assigned. Updating priority since the Test Project will only fix critical and blocking defects for the Technology Previews (Manual Test, API Recorder, and AGR) in 4.5 o accommodate the decrease in resources. Cannot contain in 4.5 plan. Required for 170651. Deferring to I6. The CellEditor in JFace Table is very commonly used, so I do think this bug should be fixed. 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 (In reply to comment #15) > The CellEditor in JFace Table is very commonly used, so I do think this bug > should be fixed. > > 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 Thanks Jimmy for your input. Yes, I think your solution would work for the JFace Table. Unfortunately, we cannot prereq SourceForge's KTable. Is there a way to extend this solution for KTables by using a custom widget resolver? Can you provide a patch for this solution? Hello, Paul, So far I don't have good idea of how to just use custom widget resolver to enable the support of in-cell editor of tables, like JFace table or KTable. The main reason is that when playback, the editor widget (Text or ComboBox) mostly does not exist, until certain method of the table widget is called to activate the in-cell editor. Based on my understanding of current mechanism of widget resolver, it will go through all found widget in the context and compare the unique id of it with the expected one. So I don't think it will be easy to achieve it just through custom widget resolver. The modification I mentioned need to be in several different places. I think I can think about providing the patch of JFace table. Also I'm thinking that if we should do some architecture level change to AGR in future, so that the extension of widget support can be more flexible. Regards, Jimmy Jin Deferring to future as approved by the TPTP PMC (http://dev.eclipse.org/mhonarc/lists/tptp-pmc/msg04926.html). Hello Jimmy Jin,
can u tell me where should i , 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";.
what is parent-referenceID?is this the referenceID of the table or table-item.
In TPTP 4.5, the AGR was moved from a Technology Preview component to an As-Is component. As-Is components are primarily provided for prior users but imply no support (for example, defects, news group, and mailing lists) or commitment to triage or resolve opened defects. For this defect to be considered, please re-open with an attached patch including code to resolve the symptom and test cases to test the fix. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |