Code generation for FormLayout creates empty stmts

[obdobion]

This code is generated when I move composite panes around relative to each other in the widget tree. I think it happens most often when the composite panes are attached to each other before I move them.

Code: Select all

    protected Control createDialogArea(Composite parent) {
        Composite area = (Composite) super.createDialogArea(parent);
        area.setLayout(new FormLayout());
        {
        }
        {
        }
        {
           idComposite = new Composite(area, SWT.NONE);
           final FormData formData = new FormData();


This is easily worked-around by moving the brackets manually. But it brings up my real question. How do I set tab order? I think it is by relative order in the widget tree, top to bottom. But that presents the problem that I don't know how to get around. I seems that I can only attach to a composite pane that is defined in the tree before (above) it.

An example of what I am trying to do is to have 3 composites that are initially each 1/3 vertical and 100% horizontal placement. The top composite (nearest the title bar) needs to expand as the window is enlarged. The lower two composites remain vertically static. I can't attach the top one's bottom to the middle one's top unless the top one is defined lower in the tree. But then the tab order starts in the middle composite; instead of where I want it, in the top composite. Any ideas are welcome.

[Eric Clayberg]

This code is generated when I move composite panes around relative to each other in the widget tree. I think it happens most often when the composite panes are attached to each other before I move them.

What version of Designer are you using? I tried reproducing this in the 1.2.2 GA but could not. In general though, you shouldn't change the relative order of widgets that are attached together as that can break the attachments.

How do I set tab order? I think it is by relative order in the widget tree, top to bottom.

The relative order (the creation order) is the same as the tab order. Changing the tab order is accomplished by dragging in the widget tree. That said, you need to be careful when widgets are attached together. We will look into having the Designer step in and prevent moves like that which would break the established attachments.

I seems that I can only attach to a composite pane that is defined in the tree before (above) it.

Correct. It needs to exist and have been instantiated before you can attach to it. If you notice, the Designer won't let you attach to a widget that is later in the tab order.

An example of what I am trying to do is to have 3 composites that are initially each 1/3 vertical and 100% horizontal placement. The top composite (nearest the title bar) needs to expand as the window is enlarged. The lower two composites remain vertically static. I can't attach the top one's bottom to the middle one's top unless the top one is defined lower in the tree. But then the tab order starts in the middle composite; instead of where I want it, in the top composite. Any ideas are welcome.

Two solutions come immediately to mind:

1) Use a grid layout for the window itself and set the first composite to grab the excess vertical space, or

2) Use a form layout with fixed attachments to the bottom of the window. There is really no need to use widget attachments in this case. Just have the bottom two composites attached directly to the bottom of the window. The top composite would then be attached to the top and bottom of the window.

In general, widget attachments should only be used in cases where you want a widget to size or position itself relative to some change in size or position of another. This is useful, for example, to attach fields to labels where the content of the labels might change due to locale (language) changes. Fixed or percentage attachments should be used for almost everything else.