Community
Participate
Working Groups
Build Identifier: I20090611-1540 import org.eclipse.swt.layout.GridLayout; import org.eclipse.swt.layout.RowLayout; import org.eclipse.swt.widgets.Button; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class Template implements Runnable { Display display; Shell shell; public static void main(String[] args) { Template test = new Template(); new Thread(test).start(); } public void run() { display = new Display(); shell = new Shell(); shell.setLayout(new GridLayout(2, false)); { Button b = new Button(shell, 0); b.setText("1"); } { Button b = new Button(shell, 0); b.setText("2"); } shell.layout(); shell.open(); test(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } private void test() { new Thread() { public void run() { try { sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } display.syncExec(new Runnable() { public void run() { shell.setLayout(new RowLayout()); shell.layout(); } }); } }.start(); } } Reproducible: Always Steps to Reproduce: 1. Run Template app 2. 2 seconds after startup, there is a layout change from GridLayout to RowLayout
You can workaround the problem using this code: Control[] children = shell.getChildren(); for (int i = 0; i < children.length; i++) { Control control = children[i]; control.setLayoutData(null); } shell.setLayout(new RowLayout()); Car, should we fix this ? Or is it the application responsability to "flush" all the layout data objects before changing the layout manager ?
I don't think anybody has ever changed layout managers on the fly before <g>. What are you really trying to do? Can it be accomplished by just using a FormLayout? (FormLayout is the best one for layout changes on the fly... see Snippet313 for an example: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet313.java). Other layouts, like GridLayout and RowLayout, have an "exclude" field in the layout data that can be turned to "true" to hide/show various components on the fly. In response to comment 1: good question. It will almost never happen. I guess we could easily check in Composite.setLayout if the new guy and the old guy have the same type, and flush if they don't. SSQ, what do you think? Should we just change the javadoc to say 'don't do that' (and then do not allow setting if non-null), or should we allow it, and flush the data for free?
I was not trying to do anything specific, just testing. I have noticed this as I was running some smoke tests on S60 eSWT. Are you suggesting that once a layout is set on Composite it can never be changed?
(In reply to comment #2) > In response to comment 1: good question. It will almost never happen. I guess > we could easily check in Composite.setLayout if the new guy and the old guy > have the same type, and flush if they don't. SSQ, what do you think? Should we > just change the javadoc to say 'don't do that' (and then do not allow setting > if non-null), or should we allow it, and flush the data for free? I believe it is the app responsability to remove any layout data it sets on controls before changing the layout "type" for the parent. Having said that, this simple app is not setting any layout datas. The layout datas are created by SWT. In this case, maybe SWT should clean after itself. Changing the java doc that way does not work, because this code would be valid but it would still fail: shell.setLayout(null); shell.setLayout(new RowLayout()); shell.layout();
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.
