Community
Participate
Working Groups
I have a GEF editor similar to VE which creates figures by scraping SWT widget images. In Draw2D 3.2, I have noticed a painting problem with Group widgets on a FigureCanvas. I am attaching a screenshot and a test case to duplicate the problem.
Created attachment 45944 [details] Screenshot showing problem See the blank space on the right side of the Group border.
Created attachment 45945 [details] Test case Test case to reproduce the problem. You will need to add draw2d to the build path and then run as SWT application.
I reproduced this, but I have no idea how our Canvas can paint on top of one of its children.
Interesting quirks about this bug. The problem goes away if: 1. The Group text is changed to "Lorem ipsum dolor" or 2. The Group width is increased to 217 (up from 187) or 3. The Group x location is changed to 0 (from 77)
To better see the problem, add this line of code: group.setBackground(ColorConstants.yellow); Note that the inner rectangle is the same width as that of the group's text and is offset from the group's top left corner by about the same amount as the group's location (ie, group's offset inside the canvas).
Within the group, the mysterious box occurs at the same location at which the group's label appears relative to its parent composite. Moving to SWT, as I can't imagine that anything GEF does would "bleed through" a child control. I tried to create a simple Canvas test case but I couldn't easily remove all of the draw2d gorp.
The culprit is the LightweightSystem. Comment the line in the FigureCanvas constructor which sets the LWS control and the mystery box disappears.
With the following snippet, the Group's outline completely disappears: public static void main (String [] args) { final Display display = new Display (); final Shell shell = new Shell (display); FillLayout fillLayout = new FillLayout(); fillLayout.marginHeight = fillLayout.marginWidth = 5; shell.setLayout(fillLayout); Canvas canvas = new Canvas(shell, SWT.NO_BACKGROUND | SWT.DOUBLE_BUFFERED | SWT.NO_REDRAW_RESIZE | SWT.H_SCROLL | SWT.V_SCROLL); canvas.getHorizontalBar().setVisible(false); canvas.getVerticalBar().setVisible(false); canvas.addPaintListener(new PaintListener() { public void paintControl(PaintEvent e) { e.gc.setClipping(e.x, e.y, e.width, e.height); e.gc.fillRectangle(e.x, e.y, e.width, e.height); } }); Group group = new Group(canvas, SWT.NONE); group.setBounds(new Rectangle(77,72,187,113)); group.setText("Lorem ipsum dolor sit amet"); shell.setSize (400, 400); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); }
SN, note that comment 8 only makes the Group's border disappear on XP; the border is still visible when I run the snippet on win2000.
Sure you can draw on top of the border of a group (on some platforms). You should only be drawing withing the client area.
(In reply to comment #10) > Sure you can draw on top of the border of a group (on some platforms). You > should only be drawing withing the client area. The group is not painting on top of its own border. The Canvas is painting on top of the group's border. That should be impossible. Remember how we painted connections in VA-Java (composite painted over top of its children)? That is not supported in SWT.
>The Canvas is painting on top of the group's border. The group's border isn't an SWT.BORDER. It is painted by the group (on Windows). If you call getClientArea() on a group, the origin will not be (0, 0). On Windows, it is possible to draw on top of a group's border.
> 0). On Windows, it is possible to draw on top of a group's border. That's a red herring. No one is drawing on the group, period. A Canvas can not paint on top of its children. I think this is related to the general problems with group borders not showing up, but it should be resolved as a dupe instead of wontfix.
Right, the group is a child of the canvas so the canvas can't draw on top.
My mistake ... reopening.
Seems that the SWT.NO_BACKGROUND bit is causing the trouble.
Here is simpler code that fails: public static void main(String[] args) { final Display display = new Display(); final Shell shell = new Shell(display); FillLayout fillLayout = new FillLayout(); fillLayout.marginHeight = fillLayout.marginWidth = 5; shell.setLayout(fillLayout); Canvas canvas = new Canvas(shell, SWT.NONE); canvas.addPaintListener(new PaintListener() { public void paintControl(PaintEvent e) { e.gc.setClipping(e.x, e.y, e.width, e.height); // e.gc.fillRectangle(e.x, e.y, e.width, e.height); } }); Group group = new Group(canvas, SWT.DEFAULT); group.setBounds(new Rectangle(77, 72, 187, 113)); group.setText("Lorem ipsum dolor sit amet"); shell.setSize(400, 400); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
