Community
Participate
Working Groups
Build ID: 3.3.1 Steps To Reproduce: When displaying results in a table column, it is very clear that when the cell has a colored background that the content of the first cell is a few pixels off to the right. We see a sliver of white to the left. Screenshot to follow. More information:
Created attachment 82179 [details] Striped table
I don't think that there's much I can do about this. Windows leaves this margin.
I might be able to do something but it seems low priortity. Closing as WONTFIX...
... you can reopen with test code, present you case a bit stronger etc.
but how are we supposed to build professional grade native-looking Eclipse-based database development IDEs with margins like that when others don't have them? :) Here is what some Joe Schmoe was able to accomplish out of his basement: http://www.sql-server-performance.com/images/nb_execution_plan_statistics1.jpg
Eh? Just attach the test code, reopen the bug and I'll see what I can do (if you care). You can probably get what you want with custom draw but let's not go there first.
Thanks Steve. Will attach a snippet in the next day or so. Any insight/workaround/fix will be greatly appreciated.
Created attachment 82221 [details] snippet to demonstrate the problem
Reopening for consideration. Steve, please let me know if the snippet is sufficient.
Here is my workaround: Start with a zero width dummy column.
(In reply to comment #10) > Here is my workaround: > Start with a zero width dummy column. This didn't work for me on XP, Vista or Windows 7.
It works for me on XP, both default and classic theme! Just took the attachment 82221 [details] snippet and changed setWidth(30) to setWidth(i == 0 ? 0 : 30) to make the white stripe disappear.
Using a dummy column is a slipper slope. You then have to deal with it when setMoveable is True. Instead of letting the table draw its own images using getColumnImage in your label provider, override PaintItem on your table, and paint the image then. If you haven't already, see the EraseItem workaround (https://bugs.eclipse.org/bugs/show_bug.cgi?id=50163) to paint the background color you want first. PaintItem is called after each EraseItem, so you can store objects looked up Erase for used in Paint in the event.item if you want as well to save computations.
Using a dummy column is a slippery slope. You then have to deal with it when setMoveable is True. Instead of letting the table draw its own images using getColumnImage in your label provider, override PaintItem on your table, and paint the image then. If you haven't already, see the EraseItem workaround (https://bugs.eclipse.org/bugs/show_bug.cgi?id=50163) to paint the background color you want first. PaintItem is called after each EraseItem, so you can store objects looked up Erase for used in Paint in the event.item if you want as well to save computations.
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.
