Bugzilla – Full Text Bug Listing
| Summary: | drawing on horizontally scrolled Table incorrect in 3.0M8 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | ArronM <arronm> |
| Component: | SWT | Assignee: | Felipe Heidrich <eclipse.felipe> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | veronika_irvine |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
Sorry, getting ahead of myself. That should read "This bug is in M8, but not in M7." And "but that problem was present in M8," is referring to the problem being in M7. FH? VI, wasn't you the last one to work in the area of problem ? I've tested the scenario in GTK 2.2.1 and GTK 2.4: Here is my finds on TableItem#getBounds(): 1) should be using gtk_tree_view_get_background_area() instead of OS.gtk_tree_view_get_cell_area() (this fixes the "shifted to the right by a few pixels" problem) 2) should not add border width of the rect.x 3) should not add header height to rect.y 4) should not add +1 to rect.width and rect.height 5) Using OS.gtk_tree_view_tree_to_widget_coords() is actually causing the bug when the widget scroll rather than fixing it. As fas as my testing goes the gtk call gtk_tree_view_get_background_area() return exactly what we want (plus the workaround for Table.CHECK to emulated Windows behaviour). I probably missing something, I will check with VI tomorrow about this. |
This bug is in M9, but not in M8. Initially, when drawing on a table, drawn items are "correctly" positioned. Horizontally scrolling the table causes the items to be moved/drawn "correctly". However, after the scrolling, hovering the mouse over the table item which was drawn on, or changing the focus (or many other things) causes the items to be drawn at an incorrect place. I put "correctly" in quotes, because they are shifted to the right by a few pixels, but that problem was present in M8, and it's a seperate (unfiled?) bug. Bug isn't present vertically. Screenshots can be provided if necessary. Code snippet follows. To test, scroll horizontally so that the 1st column is about 1/2 gone, then click the bug button. The red rectangle will be to the right of the cell it's trying to draw on. item.getBounds(int) is returning the correct values. public static void main(String[] args) { Display display = new Display(); final Color red = display.getSystemColor(SWT.COLOR_RED); final Color blue = display.getSystemColor(SWT.COLOR_BLUE); Shell shell = new Shell(display, SWT.CLOSE | SWT.TITLE); shell.setLayout(new GridLayout()); final Table table = new Table(shell, SWT.BORDER); table.setLayoutData(new GridData(GridData.FILL_BOTH)); int[] columnWidths = {150, 100, 300}; for (int i = 0; i < 3; i++) { TableColumn column = new TableColumn(table, SWT.BORDER); column.setResizable(false); column.setWidth(columnWidths[i]); } new TableItem(table, SWT.NONE); final TableItem item = new TableItem(table, SWT.NONE); item.setText(new String[] {"1", "2", "3"}); item.setBackground(0, blue); item.setBackground(2, blue); table.addPaintListener(new PaintListener() { public void paintControl(PaintEvent e) { Rectangle bounds = item.getBounds(1); GC gc = new GC(table); gc.setForeground(red); gc.drawRectangle(bounds); gc.dispose(); } }); Button btn = new Button(shell, SWT.PUSH); btn.setText("Bug"); btn.setFocus(); btn.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { // setText doesn't cause the bug, since you can also get the bug by // hovering over the tableitem item.setText(new String[] {"1", "2", "3"}); } }); shell.setSize(300, 150); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }