Bugzilla – Full Text Bug Listing
| Summary: | Group control borders disappear when tabbing between child widgets | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dave Orme <djo> | ||||||||||
| Component: | SWT | Assignee: | Steve Northover <snorthov> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | abhishek.chaudhari, ataylor, c.hauser, cbeth, crevells, eclipse.felipe, holm.tyler, kaprasannagt, ky5566, oliver.plaehn, Silenio_Quarti, smallet, sriharsha.p, sudiptaghosh2005, tom.seidel | ||||||||||
| Version: | 3.3 | ||||||||||||
| Target Milestone: | 3.3 M1 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 144685 | ||||||||||||
| Attachments: |
|
||||||||||||
*** Bug 145653 has been marked as a duplicate of this bug. *** More info: Oddly, this only occurs if you launch the snippet using "Run as | SWT Application". If you launch using shift-alt-x + s, then it runs perfectly. Additional data: When I try the following steps, I get the following results: Run as > SWT Application --> Failure Ctrl-F11 --> Works correctly ?!?! Go figure. This WORKSFORME. Is there something I am missing? Created attachment 43889 [details]
RCP application with disappearing group border and radio button controls
The bug may be related to Windows XP. And RCP applications are vulnerable. For example when we run the attached RCP application on an XP machine with Windows Classic theme the problem is even worse: we not only see the group borders disappear but all the radio buttons that are children of the group disappear as well. We can't deliver our RCP application when SWT behaves this way so it's a very serious problem for us.
David Beers (colleague of DOrme)
Created attachment 43890 [details]
Before and after screenshots
This shows what we are seeing when we run the attached RCP application on WinXP with the Windows Classic theme set. If we use the default Windows XP theme the radio buttons don't go away but the group box does. We're running the application from a launch configuration within the IDE workbench.
I should add: This only occurs the first time you traverse between the two Text controls using the tab key. Using the mouse to change move the focus to the secont Text doesn't trigger the bug. If you wiggle the shell dimensions or display another window over the application after the bug occurs the group border reappears and the bug doesn't recur when you next traverse between the text controls. But the radio buttons do not reappear unless you pass the mouse cursor or another window over them. > We can't deliver our RCP application when SWT behaves this
> way so it's a very serious problem for us.
I agree. We'll work hard on our end to recreate and fix the problem. In the meantime, you could work around the problem by redrawing the affected widgets whenever a tab is hit (yes ... this is ugly and awful, let's try and fix it first).
(In reply to comment #8) > > We can't deliver our RCP application when SWT behaves this > > way so it's a very serious problem for us. > > I agree. We'll work hard on our end to recreate and fix the problem. In the > meantime, you could work around the problem by redrawing the affected widgets > whenever a tab is hit (yes ... this is ugly and awful, let's try and fix it > first). Thanks. :-) Here's some more data from our end: With the RCP app, I get similar behavior as with standalone SWT: Launch the run configuration from the Run menu: Error Launch using Ctrl-F11: works fine Launching a deployed RCP app using the eclipse.exe launcher does *not* exhibit the bug. OS: XP Pro. Theme: Classic theme. This smells like some wierd interaction between SWT and something that is doing launching--maybe in PDE? (Dave Orme typing as himself again. Dave B is my pair programmer for the day today.) (In reply to comment #8) > > We can't deliver our RCP application when SWT behaves this > > way so it's a very serious problem for us. > > I agree. We'll work hard on our end to recreate and fix the problem. In the > meantime, you could work around the problem by redrawing the affected widgets > whenever a tab is hit (yes ... this is ugly and awful, let's try and fix it > first). Thanks. :-) Here's some more data from our end: With the RCP app, I get similar behavior as with standalone SWT: Launch the run configuration from the Run menu: Error Launch using Ctrl-F11: works fine Launching a deployed RCP app using the eclipse.exe launcher does *not* exhibit the bug. OS: XP Pro. Theme: Classic theme. This smells like some wierd interaction between SWT and something that is doing launching--maybe in PDE? (Dave Orme typing as himself again. Dave B is my pair programmer for the day today.) I can reproduce using 'Run as Java' or 'Run as SWT' but, here is weird part, I have to move the mouse around at the same time I hit the tab key. To create our RCP app, we used the PDE "RCP application with a view" template,
then replace the code in View.java with the following:
public class View extends ViewPart {
public static final String ID = "Wallace.view";
private Text text;
public void createPartControl(Composite parent) {
FillLayout fillLayout = new FillLayout();
fillLayout.marginHeight = 20;
fillLayout.marginWidth = 20;
parent.setLayout(fillLayout);
Group group = new Group(parent, SWT.NONE);
group.setLayout(new RowLayout(SWT.VERTICAL));
group.setText("Hit the tab key to make group border
disappear");
// comment out next line and the group control border doesn't
disappear anymore:
group.setBackground(Display.getCurrent().getSystemColor(SWT.COLOR_WHITE));
// comment out next line and the radio buttons don't disappear
when using
// Windows Classic theme:
group.setBackgroundMode(SWT.INHERIT_DEFAULT);
text = new Text(group, SWT.BORDER);
new Text(group, SWT.BORDER);
Button rdoOne = new Button(group, SWT.RADIO);
rdoOne.setText("Radio buttons disappear only with Windows
Classic theme");
Button rdoTwo = new Button(group, SWT.RADIO);
rdoTwo.setText("With XP Theme the radio buttons are ok");
Label lblLabel = new Label(group, SWT.NONE);
lblLabel.setText("Labels don't disappear");
Combo cboCombo = new Combo(group, SWT.NONE);
cboCombo.setText("Combo's are safe");
Button btnPush = new Button(group, SWT.PUSH);
btnPush.setText("Push buttons don't disappear");
}
public void setFocus() {
text.setFocus();
}
}
(FWIW, I'm on Platform RC6) Just to be very precise. Let it go the mouse (yes, take you hand off the mouse) and hold the tab key down. All working fine, focus moving around, border drawing. Now, still holding the tab key down, move the mouse. Border stop drawing. I can reproduce it all the time doing these steps. (In reply to comment #14) > Just to be very precise. Let it go the mouse (yes, take you hand off the mouse) > and hold the tab key down. All working fine, focus moving around, border > drawing. Now, still holding the tab key down, move the mouse. Border stop > drawing. I can reproduce it all the time doing these steps. <chuckle/> Here, it happens instantaneously when you hit TAB regardless of if you have a mouse in action (or trackball, or both, as we have here). This doesn't fail for me on my machine but it does fail on Felipe's when the mouse is wiggled. We'll debug there ... stand by ... Fixed > 20060608 NOTE: It is fixed on Felipe's machine with all the mouse wiggling. I'm assuming that it's the same problem you are seeing but it could be that you are seeing something different. If so, then please reopen this bug report. Thanks Steve! I'll let you know if this doesn't resolve the issue for us. Am I correct in understanding that this fix should appear in the first 3.3 stream nightly builds? Thanks again! Yes. The code is NOT in 3.2. Hope this works for us! We are experiencing the same kind of problem after migrating to Eclipse 3.2 with the RCP application we are developing. Unfortunately, for us at least, the bug does *not* go away when we are using a recent 3.3 nightly build (N20060705-0010) as target platform, as I suppose it should. I am relatively new to Eclipse RCP development, so could you please confirm that what I did should make the bug disappear, before I re-open this bug report? Thanks! Here goes: First, in order to reproduce the bug in Eclipse 3.2, I used the "New Project Wizard" to create a new "Plugin project" using the "Plug-in with a view" template, and replaced the source code in View.java with the one contained in post 12 above. Sure enough, starting an Eclipse application (using context menu "Run as", "Run...") and opening the view exhibits the faulty behaviour described above. Next, I've proceeded to download and unzip the version 3.3 nightly build N20060705-0010, changed the "target platform" preference in my development Eclipse (3.2) to point to that new Eclipse version, and re-started the application. The bug is still there. Finally, I re-did the steps above using the version 3.3 nightly build as both development and target platform -- still no luck. Is this bug fix simply not yet contained in the v3.3 nightly builds, or am I missing something here? Thanks in advance for your help! The code should be released, reopen the bug. Since I can't make it happen on my machine and the mouse wiggling is necessary on Felipe's machine, we will have to debug with you through this bug report. David, was this ever fixed for you? Since our code base is in lockdown mode for a September ship date, we haven't attempted to migrate anything to the 3.3 stream. We just found a workaround (I believe) using Display.addFilter() and refresh() and have gone with that. Steve, thanks for the quick reply. Let me know how I can assist you in debugging this. It seems that I cannot change the "Status" of this bug to "reopen" or am not allowed to. Dave: Could you explain your workaround in a bit more detail? We would very much like to have a workaround available as well. Thanks! I'll reopen it and email myself at work to remember to look up the workaround we found. (One of my colleagues wrote it so I don't know the details off the top of my head.) Steve: Any news here? I am very willing to help debugging this thing but do need some instructions from your end. Also note that I will not be in my office the next two weeks starting on Monday. Best, Oliver (note: Steve is currently on vacation for a couple of weeks) Here's what we do to work around this:
control.addFocusListener(forceRedrawHandler);
FocusListener forceRedrawHandler = new FocusListener() {
public void focusGained(FocusEvent e) {
// no op
}
public void focusLost(FocusEvent e) {
Control control = (Control)e.widget;
Composite root = getRootComposite(control);
redrawChildNodes(root);
}
private Composite getRootComposite(Control control) {
Composite parent = control.getParent();
if (!(parent instanceof Form)) {
parent = getRootComposite(parent);
}
return parent;
}
private void redrawChildNodes(Composite composite) {
Control[] children = composite.getChildren();
for (int i = 0; i < children.length; i++) {
Control child = children[i];
// We only want to redraw radio Buttons and Group controls.
// For composites we recurse into their children. For TabFolders
// we recurse only into the active TabItem.
if (child instanceof Button) {
child.redraw();
} else if (child instanceof Group) {
child.redraw();
redrawChildNodes((Composite)child);
} else if (child instanceof CTabFolder) {
CTabFolder tabFolder = (CTabFolder)child;
Composite selectedItem =
(Composite) tabFolder.getSelection().getControl();
redrawChildNodes(selectedItem);
} else if (child instanceof Composite) {
redrawChildNodes((Composite)child);
}
}
}
};
bug 150024 is related. Per Randy Hudson on platform-swt-dev, perhaps bug 150024 is a dupe of this? Dave: Thanks for the workaround! It sort of works but only for controls that are under my thumb. I cannot access the toggle control in section titles, e.g., so if the focus leaves that toggle control, the radio buttons still disappear. To get around this, I ended up applying the workaround directly to org.eclipse.swt.widgets.Control and patching my target platform's org.eclipse.swt.win32.win32.x86_<version>.jar That does work, for sure, but I somehow don't like that "solution" and would still prefer a real fix for the cause of the problem. ;-) Best, Oliver Remember that we can only recreate it by wiggling the mouse on Felipe's machine (which looks like a different problem) so we will need to debug, step by step, this with the people on this bug report. First thing to find out: Does the code that we released fix anyone? Dave, can confirm that the code that is released does not fix your case? Does replacing Group.WM_UPDATEUISTATE() with the following code fix the problem?
LRESULT WM_UPDATEUISTATE (int wParam, int lParam) {
LRESULT result = super.WM_UPDATEUISTATE (wParam, lParam);
if (result != null) return result;
/*
* Feature in Windows. When WM_UPDATEUISTATE is sent to
* a group, it sends WM_CTLCOLORBTN to get the foreground
* and background. If drawing happens in WM_CTLCOLORBTN,
* it will overwrite the contents of the control. The
* fix is draw the group without drawing the background
* and avoid the group window proc.
*
* NOTE: The DefWindowProc() must be called in order to
* broadcast WM_UPDATEUISTATE message to the children.
*/
boolean redraw = findImageControl () != null;
if (!redraw) {
if ((state & THEME_BACKGROUND) != 0) {
if (OS.COMCTL32_MAJOR >= 6 && OS.IsAppThemed ()) {
redraw = findThemeControl () != null;
}
}
if (!redraw) redraw = findBackgroundControl () != null;
}
if (redraw) {
if (OS.IsWinCE) {
OS.InvalidateRect (handle, null, false);
} else {
int flags = OS.RDW_FRAME | OS.RDW_INVALIDATE | OS.RDW_ALLCHILDREN;
OS.RedrawWindow (handle, null, 0, flags);
}
int code = OS.DefWindowProc (handle, OS.WM_UPDATEUISTATE, wParam, lParam);
return new LRESULT (code);
}
return result;
}
*** Bug 151983 has been marked as a duplicate of this bug. *** I'll check--hopefully this coming week. Thanks Steve. (In reply to comment #32) > Does replacing Group.WM_UPDATEUISTATE() with the following code fix the > problem? > LRESULT WM_UPDATEUISTATE (int wParam, int lParam) { > LRESULT result = super.WM_UPDATEUISTATE (wParam, lParam); > if (result != null) return result; > /* > * Feature in Windows. When WM_UPDATEUISTATE is sent to > * a group, it sends WM_CTLCOLORBTN to get the foreground > * and background. If drawing happens in WM_CTLCOLORBTN, > * it will overwrite the contents of the control. The > * fix is draw the group without drawing the background > * and avoid the group window proc. > * > * NOTE: The DefWindowProc() must be called in order to > * broadcast WM_UPDATEUISTATE message to the children. > */ > boolean redraw = findImageControl () != null; > if (!redraw) { > if ((state & THEME_BACKGROUND) != 0) { > if (OS.COMCTL32_MAJOR >= 6 && OS.IsAppThemed ()) { > redraw = findThemeControl () != null; > } > } > if (!redraw) redraw = findBackgroundControl () != null; > } > if (redraw) { > if (OS.IsWinCE) { > OS.InvalidateRect (handle, null, false); > } else { > int flags = OS.RDW_FRAME | OS.RDW_INVALIDATE | > OS.RDW_ALLCHILDREN; > OS.RedrawWindow (handle, null, 0, flags); > } > int code = OS.DefWindowProc (handle, OS.WM_UPDATEUISTATE, > wParam, lParam); > return new LRESULT (code); > } > return result; > } *** Bug 151665 has been marked as a duplicate of this bug. *** We are using Composite instead of Group, so I added your code to the former (where it belongs I think). This does indeed get rid of the bug! :-) Thanks Steve! Any chance of this fix being included in a 3.2 build? Yes ... but as far as I knew, the bug only happened for group widgets. Do you have some code that makes it happen for you that does not involve a group widget? Also, can everyone confirm that the problem only happens in the 'Windows Classic' theme? (In reply to comment #37) > Yes ... but as far as I knew, the bug only happened for group widgets. Do you > have some code that makes it happen for you that does not involve a group > widget? Take Dave's code from comment #12, replace Group with Composite, and outcomment the line "group.setText...". For me, same behavior as with a Group: After the first tab press, the radio buttons disappear. > Also, can everyone confirm that the problem only happens in the 'Windows > Classic' theme? I can confirm that it happens under Windows XP in Windows Classic theme, also in Windows XP theme with "Windows Classic Style" chosen for "Windows and buttons" and "Windows Standard" for "Color scheme" (both on "Appearance" tab of the "Display properties" dialog). It does *not* happen under Windows XP when using "Windows XP theme" unmodified. It does also not happen under MacOS X. I haven't tested Linux or Unix. Best, Oliver Oliver, can you confirm that the bug happens to you with the latest SWT code from HEAD? I'd love to, but need some assistance here. How do I do this, preferably with a minimum of fuss and network traffic (connection at my workplace is a bit slow)? Do I have to download all of /cvsroot/eclipse per anonymous cvs and build it? If so, how do I build it? Or is a subset sufficient? Or can I simply download and use the most recent nightly build? If so, which version/date? Please bear with me, I'm not that proficient with the whole Eclipse / RCP thingy yet. ;-) Best, Oliver I've found this page: http://www.eclipse.org/swt/cvs.php and followed the instructions on it. And yes: The bug is still there when using the current head of SWT. Best, Oliver Thanks Olivier. It fails on my machine too. But again, I need to move the mouse. Ok, over to Felipe's machine. Oliver, please get the latest from HEAD and try it now. DO NOT test the group case. Only test the composite case. Thumbs up! The composite case works fine with the latest head of SWT. :-) Ok, slowly but surely we are zeroing in. Does the group case fail for you? If so, does the code from comment 32 fix it for you? (In reply to comment #46) > Ok, slowly but surely we are zeroing in. Does the group case fail for you? No, it doesn't. Works fine with the current head of SWT. And so does Composite. :-) Dave, does the code from HEAD fail for group for you? Does the code for group in this bug report fix it? This is a serious issue that I'd like to resolve. We can't have controls disappearing on people! I'm on vacation right now and will ping my colleague when I get back to see if he verified this. :-) You! Stop reading this email and go and vacate! Right now!! I came across this issue with the group disappearing after pressing tab (only if the group's background or foreground color was set). I just thought I would let you know that I got the lastest SWT code from HEAD and this issue is now resolved for me in the application. Darn, still can't mark this fixed ... The current thinking is that the code in HEAD fixes everything but the group case that David Orme is seeing. When he is back from vacation, we can continue debugging with him remotely, starting with the code from comment 32. If anyone else on this bug report is still seeing the bug with the code from HEAD, speak up now! *** Bug 155533 has been marked as a duplicate of this bug. *** Could you please explain what the latest code from HEAD means? Is this the current download from eclipse.org/swt? Yes. Please get a nightly or better yet, get SWT from CVS right now and run your test case against it (see http://www.eclipse.org/swt/cvs.php). I'm back from vacation but we're supposed to be shipping code soon... We'll get to this ASAP. Thanks for your patience. Dave, do I still have the bug? Thanks for your patience Steve. I dropped in the N20060917 plugin from the RCP SDK drop and things look good so far. If you don't hear from me again in two days or so, you can consider this closed from our end. :-) Thanks again. (And our shipment two weeks ago went well.) Dave, do I still have the bug? Not from our end; Resolved/FIXED. Thanks. Could someone confirm whether this fix went into 3.2.2? The fix is not in 3.2.x (the Target Milestone field would indicate this). Are you seeing this problem? I repeat, are you seeing this? 3.2.2 is in the final stages and a new submission from SWT is unlikely. We opened http://bugs.eclipse.org/bugs/show_bug.cgi?id=155533, which was set to be duplicat of this bug. We are moving to 3.2.2 release, that's why I am interest in whether this has fixed in 3.2.2 or not. I can not reproduce http://bugs.eclipse.org/bugs/show_bug.cgi?id=155533 any more, however I will need to ask our customer to verify. Ok, if this is still happening in 3.2.2 (which is should be), then we can look into fixing it for 3.2.3 (if such a thing ever exists). You will need to ping this bug report at that time. NOTE: This bug will remain closed until someone provides a test case I can use that shows the problem. The following fails for me in 3.2.1. Remove the commented line to see the group's border disappear:
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();
}
Reopening. The above snippet fails on M5 if you remove the commented line. The SWT.DEFAULT constant use is a type. You can see the bug with NONE or BORDER also. (In reply to comment #68) > Reopening. The above snippet fails on M5 if you remove the commented line. > The SWT.DEFAULT constant use is a type. I meant "typo". M5 refers to 3.3. Does this have anything to do with tabbing? Please open a new bug report with the snippet and add me. (In reply to comment #70) > Does this have anything to do with tabbing? Please open a new bug report with > the snippet and add me. Correct, it has nothing to do with tabbing. But it is "Group control borders disappearing". The original description included unnecessary steps to show the problem, so? I've just simplified the test case. Maybe I should open two bugs: 1) Group Control Borders Disappearing 2) Group Control Borders Disappearing, and my mom's birthday is in November. Don't be a dork, just enter the new bug report. See comment 28. I've updated the summary since it was quite stale. Steve, In response to comment #65, I'd kindly like to request a fix for this on the 3.2 maintenance branches; our commercial RCP app, and soon-to-be commercial Platform app makes heavy use of the widgets that are affected by this bug; the group and radio buttons dissapearing. As you can imagine, Groups are a very powerful tool for a good usability experience, and losing the title of a group (nevermind the border) is a huge bug. Losing radio buttons in other widgets when classic theme is on just makes it a killer! I believe there are enough test cases attached to this ticket against 3.2 right? The easiest one (to see the radio buttons dissapearing) is: Get an XP box. Switch to classic theme. Open eclipse 3.2.2. Open a manifest editor, go to the runtime tab, have some entries in enumerated packages, click one and start tabbing; enjoy the radio buttons on the right ("package visibility") dissapearing! The mouse-wiggling also affects what happens, too. Thank you very much for your concern, Felipe, Steve and the rest of the team. Ok, Felipe and I will look into it. If we can't make it happen on our machine, we will have to debug with you remotely on your machine (ie. send you code to try etc). I don't know when (or if) there will be an Eclipse 3.2.3. You may have to attach a patch and ship like that. Created attachment 65869 [details] patch patch for the 3.2.2 stream (R3_2_maintenance) I verified that the problem happens only on Eclipse 3.2.2 (Note, on my machine I have to move the mouse in order to reproduce the problem). The fix released 8/6/2006 changed Button.java and Group.java. The first version to include the fix is v3301 (Button.java 1.83 and Group.java 1.61). I was able to load eclipse 3.2.2 compare the changes and generate the patch for the problem. Running with the patch I could verify both snippets (comment #1 and #12) fixed and the problem with eclipse (comment #74) fixed as well. Thanks Felipe for finding the code. I need to take a look at it with you, comparing it with what we are doing in 3.3, to make sure that the patch is complete (and that it is fixed in 3.3). BTW, Eddie, if you run your code against SWT 3.3 M7, is the problem fixed for you by the code in HEAD? We release the fix in the maintenance stream (R3_2_maintenance). If they ever build 3.2.3 this fix will be in automatically. *** Bug 210832 has been marked as a duplicate of this bug. *** *** Bug 221285 has been marked as a duplicate of this bug. *** It seems that this one doesn't reproduce anymore with Windows XP Service pack 3 and even with Eclipse 3.2.2. The environment I am using is: Eclipse: 3.2.2 jdk: 1.5.0_16 OS: Windows XP Service Pack 3 with Windows Classic Theme That's good to know. Created attachment 160918 [details]
Project to demonstrate label text disapper
This is a zip of the project's folder.
To run the project usual rules apply :
Unzip and import project in Eclipse.
Run as Eclipse Application.
But please make sure windows classic theme is set in windows xp.
I developed and tested this on :
jdk-1.6-u1
Eclipse 3.4.2
I believe I have run into this bug and as I see no solution for the problem after doing many internet searches. For the plug-in we have added a label (control) to a view's toolbar. The text of this label partially disappears when 'Windows classic theme' is selected for Windows XP. The label is supposed to show vital information and we can't afford to let it get hidden or partially disappear. More painful when reported by customer :-(! Please fix this asap. Attached is the demo project's zip. (comment#83) |
In the following snippet, the first time you tab from the first to the second widget the border of the parent Group control disappears. If you resize the shell or make another window active on top of it and then return to the shell the borders repaint. public class GroupBorderBug { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); Group group = new Group(shell, SWT.BORDER); group.setText("Some text"); group.setBackground(Display.getCurrent().getSystemColor(SWT.COLOR_WHITE)); group.setLayout(new RowLayout(SWT.VERTICAL)); new Text(group, SWT.BORDER); new Text(group, SWT.BORDER); shell.setSize(800, 600); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } } } This occurs only in the instance where the background color has been set on the Group control. Comment out group.setBackground(...) and it works normally. Note: this was originally thought to be a bug in FormToolkit since using formToolkit.adapt(group) produces the same result.