RE: [platform-swt-dev] ordering problem adding buttons to a GridLayout

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

Thanks Brad,

1) Fixed > 20031022
2) From the SWT Home Page, "SWT
component is designed to provide efficient, portable, access to the user-interface
facilitites of the operating system", not facilitate GUI builders.
3) Layout is not automatic when a child
is added or deleted or hidden etc.  This was done for efficiency.

Sorry if the responses are short.  I'm
in a rush now.  We can discuss this later.

"Brad O'Hearne" <brado@xxxxxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 10/21/2003 03:55 PM Please respond to platform-swt-dev

To:        <platform-swt-dev@xxxxxxxxxxx>         cc:                 Subject:        RE: [platform-swt-dev] ordering problem adding buttons to a GridLayout

Steve,

>1) Post Code
I didn't originally do this because it was strewn about various classes
and
wouldn't make a good example.  However, I have attached a Test class
that
demonstrates nicely the problem.  I also posted it inline below (don't
know
what the preference is):

---------------------

import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class Test {

public static void main(String[] args) {
Test t = new Test();
try {
t.start();
} catch (Exception ex) {
ex.printStackTrace();
}
}

public void start() throws Exception {
Display display = new Display();
Shell shell = new Shell(display);
shell.setText("Test");
shell.setSize(400, 300);

GridLayout gl = new GridLayout();
gl.numColumns = 2;
shell.setLayout(gl);

Shell nullParent = new Shell();

Button b1 = new Button(nullParent, SWT.PUSH);
GridData gd = new GridData(GridData.FILL_BOTH);
b1.setLayoutData(gd);
b1.setText("button1");

Button b2 = new Button(nullParent, SWT.PUSH);
gd = new GridData(GridData.FILL_BOTH);
b2.setLayoutData(gd);
b2.setText("button2");

b1.setParent(shell);
b2.setParent(shell);

shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}

display.close();
}

}

---------------------

>>(something that unfortunately has to be done
because SWT
>>widgets have no default constructor)

> Why does this have to be done?

I recall there was a thread maybe about a 8 months
to a year ago discussing
this issue in relation to GUI builders -- the same general issue exists
here.  The issue revolves around loading class instances dynamically
using a
classloader.  Classes oriented toward external "manipulation"
(for lack of a
better word) tools in general should always provide parameterless
constructors, otherwise, this cannot be done.  Widgets are pretty
obvious
candidates for such tools, and therefore such instantiation.  For
various
reasons, the parent might not be immediately available when the child is
instantiated.  To get around this, I was using a dummy Composite as
a filler
so that the Control could be instantiated independently of the final parent,
then when the parent could be combined, resetting the parent.

It looks as if this approach isn't going to work.
 I suppose assuming the
parent exists and is accessible was a nice assumption for building the
API,
though if I could make a suggestion, I would strongly recommend not imposing
this requirement on the entire SWT API, as it really doesn't consider the
potential external uses of the API.  Adding parameterless constructors
would
be a big improvement.

> 3) Use moveAbove() to change the Z-order to be
the order you want or
reverse the calls to setParent().

?  I'm not quite following.  If setParent()
is being performed with a shell
that has no children, why wouldn't the Shell's layout handle child additions
in left to right order, as the layout dictates?  It seems strange
to have a
left to right handling if added to the Shell on Control creation, but right
to left order if added to the Shell using setParent.  Also, I probably
couldn't make this work anyway.  This is all happening dynamically,
and
reordering the creation of the GUI tree is not ideal.  I guess a better
question is this -- what is the expected behavior of setParent() with
relation to the parent's layout?

BradO



#### Test.java has been removed from
this note on October 22, 2003 by Steve Northover