Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321489

Summary:	[TreeItem] getBounds(int columnIndex) returns wrong bounds
Product:	[RT] RAP	Reporter:	Bogdan B. <bbarzu>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	P3	CC:	bbarzu, tbuschto
Version:	1.4
Target Milestone:	1.4 M2
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	320597

Description Bogdan B.

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.

2010-08-02 07:50:20 EDT

I just tested with a Table instead of a Tree - everything works fine.

Comment 2 Ivan Furnadjiev

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.

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

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

2010-09-09 01:01:17 EDT

The issue with scrolling is fixed in CVS HEAD.