Community
Participate
Working Groups
pre. TableItem item = ...; itemBounds = item.getBounds( column ); imageBounds = item.getImageBounds( column ); The code in TableEditor#computeBounds seems to rely on the fact that itemBounds.x == imageBounds.x which holds true at least under Windows XP and GTK. If there is an offset between itemBounds.x and imageBounds.x, as it is the case with table padding in RAP, then the computed bounds will exceed the right edge of the cell by the amount of this offset. Example: pre. +-+-------+-+------------+-+ | | | | | | | | img | | text | | | | | | | | +-+-------+-+------------+-+ 0 2 ... 18 ... 100 |<-------------->| editor In this example, itemBounds would be (0, 0, 100, y), imageBounds would be (2, 0, 16, y). The computed bounds would be (18, 0, 84, y) instead of expected (18, 0, 82, y), because the 2px left image offset are missing in the computation. I'll attach a patch that fixes the problem.
Created attachment 133090 [details] Patch against linux GTK version This patch adds another optimization: the left offset is only applied to the editor bounds if there is an image. For columns without image, the editor starts at the left edge of the cell. This improves the layout in case the table has a padding, as it is the case in RAP. Please note that this patch does not change the existing layout in SWT.
(In reply to comment #0) > itemBounds.x == imageBounds.x which holds true at least under Windows XP and > GTK. In XP and GTK, TableEditor#computeBounds is working fine then ? Where does it fail ? In the patch I see 'if (rect.width > 0)' , is there a reason for that ? Are you getting negative width somewhere ? I'm trying to determine if the problem is in TableEditor or in TableItem#getImageBounds. Steve, is itemBounds.x == imageBounds.x expected to be the same ?
(In reply to comment #2) > In XP and GTK, TableEditor#computeBounds is working fine then ? > Where does it fail ? The problem exists in RAP (www.eclipse.org/rap), where we have configurable cell paddings (but still strive for using as much original SWT code as possible). I think the question is whether the case that imageBounds.x > itemBounds.x is considered valid. > In the patch I see 'if (rect.width > 0)' , is there a reason for that ? Are you > getting negative width somewhere ? As I explained in comment 1, this makes editors begin at the very left edge in case there is a cell padding. The meaning is: "If there is an image, let the editor begin after the image, otherwise let it span the entire cell".
> Steve, is itemBounds.x == imageBounds.x expected to be the same ? Certainly not in a tree. We return whatever the platform provides for the image and text bounds. If there is extra space on the platform, then the bounds have extra space. Custom draw table and tree listeners can use the image and text bounds to draw the same way as the platform. Having said all that, do we have a bug?
Can you attach a SWT snippet that shows the problem ? I'll have it fixed post 3.5. Thank you
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
