Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 321489 - [TreeItem] getBounds(int columnIndex) returns wrong bounds
Summary: [TreeItem] getBounds(int columnIndex) returns wrong bounds
Status: RESOLVED FIXED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 1.4   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: 1.4 M2   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 320597
  Show dependency tree
 
Reported: 2010-08-02 06:15 EDT by Bogdan B. CLA
Modified: 2010-09-09 01:01 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Bogdan B. CLA 2010-08-02 06:15:51 EDT 
Build Identifier: 1.3

The RAP 1.3 implementation of TreeItem.getBounds(int columnIndex) does not correctly treat the swapping of two columns. It does not take the swapping under consideration, as RCP does (tested with Eclipse 3.4). Which has the effect of getting the wrong cell editor.

If considering fixing this bug, please specify whether this will be fixed for the old (1.3) Tree, or for the new one (1.4 - specified by Bug #309519)!

Reproducible: Always

Steps to Reproduce:
1. Having let's say a tree with at least 3 columns, having different cell editors for the columns at indexes 1 and 2 (first two after the column presenting the tree). Let-s say 1-st column is "name" and the 2-nd is "description"
2. swap the 2 columns (replace one with the other by dragging the header of "description" and dropping it right between the 0-indexed-tree-column and "name")
3. click on a cell in "name".

You would expect now to edit the "name", but, unfortunately, the editor for "description" is activated.

Why? Because:
- in RCP: TreeItem.getBounds(1) returns the rectangle of the cell CURRENTLY under the column "name" - which now includes the mouse-down-pointer
- in RAP: TreeItem.getBounds(1) returns the rectangle of the cell INITIALLY under the column "name"- which now DOES NOT include the mouse-down-pointer
Comment 1 Bogdan B. CLA 2010-08-02 07:50:20 EDT 
I just tested with a Table instead of a Tree - everything works fine.
Comment 2 Ivan Furnadjiev CLA 2010-08-10 07:44:43 EDT 
I've just tested moveable tree columns and TreeItem#getBounds( index ) against CVS HEAD (new Tree implementation) and it works as expected. The TreeItem#getBounds( index ) returns the bounds of the current tree cell position. I think that this issue has been fixed by Bug #309519. Bogdan, can you confirm this? Please, reopen this bug if the problem persist with CVS HEAD.
Comment 3 Bogdan B. CLA 2010-09-07 11:36:13 EDT 
I added a code snippet for another bug, but which tests implicitly this bug too:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=324651#c5

That snippet confirms that this bug was fixed in 1.4M1.
Comment 4 Ivan Furnadjiev CLA 2010-09-08 03:59:46 EDT 
I will reopen this bug as bounds are still wrong in case of scrolling.
Comment 5 Ivan Furnadjiev CLA 2010-09-09 01:01:17 EDT 
The issue with scrolling is fixed in CVS HEAD.