Sneak Preview: New Code Generation Options

[Eric Clayberg]

Many new code generation options are available now in the v1.2.4 beta of SWT Designer Professional.



Support for flat mode (e.g., create components within the same scope rather than in separate blocks)
Prefix (separate) component creation with blank lines or custom comments
Declare variables at the top of the method or where first assigned
Optionally declare widget variables as final
Share variables like "girdData", "formData", "label", "button", etc.
Automatically create event handler stub methods

Comments? Suggestions?

[aspinei]

It would be nice to be able to declare the variables as class attributes. Sometimes, common behavior is shared by different widgets via the same function in the class, which performs a specific action upon other widgets in the same composite.
It would also be interesting (altough harder to implement, I think) to be able to use custom widgets which simply inherit Canvas. As in Visual Studio, these widgets would be rendered by a grey box with the word "custom" inside it.
Kudos for a great product.
Adrian

[Eric Clayberg]

It would be nice to be able to declare the variables as class attributes. Sometimes, common behavior is shared by different widgets via the same function in the class, which performs a specific action upon other widgets in the same composite.

Note that Designer does provide a toolbar button to convert widgets from local variables into fields. We also plan to add an additional code generation option to allow you to specify on a class by class basis which widget types should be declared as fields or local variables by default (i.e., have Labels created as local variables and Text widgets as fields). You woudl also be able to specify the default initial variable names for different types (like "gd" for GridData).

It would also be interesting (altough harder to implement, I think) to be able to use custom widgets which simply inherit Canvas. As in Visual Studio, these widgets would be rendered by a grey box with the word "custom" inside it.

Actually, you can do that now by dropping in a Canvas widget and then changing the class type in the source code. The Designer can support any subclass of a known type in this manner. Eventually, we want to add the ability to select and place a custom widget from within the editor or morph a widget into any subtype.

[aspinei]

We also plan to add an additional code generation option to allow you to specify on a class by class basis which widget types should be declared as fields or local variables by default (i.e., have Labels created as local variables and Text widgets as fields). You woudl also be able to specify the default initial variable names for different types (like "gd" for GridData).

That's excellent news !

Actually, you can do that now by dropping in a Canvas widget and then changing the class type in the source code.

I see, thank you for the tip.

Adrian

[pjchristopher]

When is this suppose to be released?

[Eric Clayberg]

When is this suppose to be released?

We hope to start beta testing the new code generation features next week (once we are all back from EclipseCon ).

[Hansz]

looking goooooooooooooood ...

[Eric Clayberg]

When is this suppose to be released?

We hope to start beta testing the new code generation features next week (once we are all back from EclipseCon ).

These features are now available in the new v1.2.4 beta.

Note that these new code generation options are brand new and are undergoing beta test during the 1.2.4 release cycle. Please report any anomalies to support@swt-designer.com. Also note that these new options apply to any new code that you create, not to existing code. If you have a window that was already laid out using block mode, these new options will not translate them. If you switch modes, you will get a mix of old style and new style in the same class as you add new widgets. We plan to add an option to automatically detect which code generation styles are in effect for a given window and have the Designer automatically adjust on a case by case basis (e.g., new windows would use the new settings, but existing windows would continue to use whatever settings were in effect when they were created.