Bugzilla – Full Text Bug Listing
| Summary: | TableEditor doesn't track moving of cells properly | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Max Rotvel <rotvel> | ||||||
| Component: | SWT | Assignee: | Veronika Irvine <veronika_irvine> | ||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | ||||||||
| Version: | 3.2 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Max Rotvel
Created attachment 37283 [details]
Testcase incl. workaround
Compile and run the testcase. Delete rows by using the buttons.
If deleting a row causes the underlying row to be shifted up, the button isn't moved with it. Enabling the workaround makes the button move with the row correctly (by forcing a TableEditor.resize() - all the fun stuff is in the 'selector' Listener)
Created attachment 37670 [details]
Testcase w. better workaround
Testcase with a much nicer workaround.
As far as I can see it is not possible to make TableEditor track the cell correctly in the case where a TableItem moves without changing it's TableColumn (because TableItem doesn't publish the move or resize events), at least not without hacking into the paint event and doing something nasty there. A solution could be to just update the Javadoc to mention the case where it doesn't work and perhaps the workaround.
|