Properties for custom controls

[cjr]

I'd like to create some custom controls (just composites of existing things, really) and it looks like designer has some support for doing this.

What I can't work out - and it might be lack of familiarity with Java that's the problem - is how does designer determine what values are permitted for various exposed "properties"?

For instance, most of the SWT built-in controls have constructors that take an 'int style' argument, and the designer works out what SWT.* values are permitted.

I'd essentially like designer to call the constructors of my new controls with valid (and non-SWT) style arguments.

Does this make any sense?

Thanks in advance,

Chris

[Eric Clayberg]

I'd like to create some custom controls (just composites of existing things, really) and it looks like designer has some support for doing this.

Here's an example project showing how to create custom property editors and customizers with Designer.

The example requires the latest v4.2.1 build.

[cjr]

Here's an example project showing how to create custom property editors and customizers with Designer.

The example requires the latest v4.2.1 build.

Thanks very much - this looks like what I need. I'm having some problems building and using it, but I think that's just a lack of Eclipse familiarity here.

I noticed you've used Java 5 code. Is that a requirement of your custom control API, or was it just the way you decided to implement the examples?

Cheers,

Chris

[Eric Clayberg]

I noticed you've used Java 5 code. Is that a requirement of your custom control API, or was it just the way you decided to implement the examples?

Java 5 is not required in any way. If you are referring to the SWTResourceManager class, that is automatically generated into your project in either JDK 1.5 or 1.4 format depending on what you are using. Both versions of that class are provided in the plugins\com.swtdesigner_4.2.1\supplied_src and plugins\com.swtdesigner_4.2.1\supplied_src5 directories.

[cjr]

Java 5 is not required in any way. If you are referring to the SWTResourceManager class

You're right, sorry.

I got the MyButton bean working OK, though cannot figure out how to use the MyButtonCustomizer class. Any clues?

I note that a widget which extends a Composite (creating several native sub-widgets, say) simply gets drawn as a grey rectangle in design mode. Is there any way to change this? I'd like to be able to have the designer display something else (like some placeholder text) while in design mode, ideally without having to include custom paint code in code that we want to ship. If that isn't possible, is there some kind of "am_I_running_in_the_designer" test we can use to conditionally add our own paintListener?

Is there a way to customize the default values of custom properties?

We will need to build our custom widgets against your api_src code; are you intending to release new versions of this in conjunction with the designer? I'm wondering how best to manage this in our source tree.

[Eric Clayberg]

I got the MyButton bean working OK, though cannot figure out how to use the MyButtonCustomizer class. Any clues?

Right-click on the widget and select Customize.... That will open whatever customizer has been defined for the class.

I note that a widget which extends a Composite (creating several native sub-widgets, say) simply gets drawn as a grey rectangle in design mode.

That sounds odd. The widget should look exactly the same in design time and at runtime. Are the sub-widgets statically defined, or are they created dynamically at runtime (so that they would not exist at design time)?

Is there any way to change this? I'd like to be able to have the designer display something else (like some placeholder text) while in design mode, ideally without having to include custom paint code in code that we want to ship. If that isn't possible, is there some kind of "am_I_running_in_the_designer" test we can use to conditionally add our own paintListener?

Designer supports the standard Beans.isDesignTime() check provided by the JDK. That should return true when your widget is running in Designer (or any GUI builder for that matter).

Is there a way to customize the default values of custom properties?

Did you try initializing the default values in your widget class itself?

We will need to build our custom widgets against your api_src code; are you intending to release new versions of this in conjunction with the designer? I'm wondering how best to manage this in our source tree.

All of the api_src is available in the plugins\com.swtdesigner_4.2.1\api_src directory. Any updates will always be in that directory and will match the associated Designer build. This public API is new to v4.2.1 and will almost certainly be enhanced in the future.

You can use the api_src code any way you like. You can copy it into your project (as was done with the example), or you could compile against the designer.jar as a prereq.

[cjr]

Right-click on the widget and select Customize.... That will open whatever customizer has been defined for the class.

Aha. While the Customize menu does appear on both Linux and Solaris, nothing seems to occur when you click it. A call to System.out.println() put into the customizer's constructor doesn't get called either.

That sounds odd. The widget should look exactly the same in design time and at runtime. Are the sub-widgets statically defined, or are they created dynamically at runtime (so that they would not exist at design time)?

They're all created statically. I'm confused that you think the widgets should look the same at design time and runtime (or when you click the test button), because AFAICS the design time display is a sort of non-native simulation of the widgets. They definitely do not look like GTK widgets at design time for instance on Linux/Solaris, though they do at test/runtime (following GTK themes and so on).

Designer supports the standard Beans.isDesignTime() check provided by the JDK. That should return true when your widget is running in Designer (or any GUI builder for that matter).

OK, thanks. Hopefully I won't need to use this if the Composite draws itself as you're claiming it should...

Did you try initializing the default values in your widget class itself?

Doh. Yes that works fine - too easy!!

All of the api_src is available in the plugins\com.swtdesigner_4.2.1\api_src directory. Any updates will always be in that directory and will match the associated Designer build. This public API is new to v4.2.1 and will almost certainly be enhanced in the future.

You can use the api_src code any way you like. You can copy it into yoru project (as was done with the example), or you could compile against the designer.jar as a prereq.

Thanks.

[Eric Clayberg]

While the Customize menu does appear on both Linux and Solaris, nothing seems to occur when you click it.

Is that also the case with the example project I provided?

Is this a problem limited to Unix/Linux, or do you see it under Windows as well?

They're all created statically. I'm confused that you think the widgets should look the same at design time and runtime (or when you click the test button), because AFAICS the design time display is a sort of non-native simulation of the widgets. They definitely do not look like GTK widgets at design time for instance on Linux/Solaris, though they do at test/runtime (following GTK themes and so on).

Can you provide a screen shot of what you are seeing at runtime and design time?

Do you have the Designer > General > Use Draft Mode preference turned on? Unless you have Draft Mode turned on, the widgets should look the same at design time and in test/preview mode.

[cjr]

Do you have the Designer > General > Use Draft Mode preference turned on? Unless you have Draft Mode turned on, the widgets should look the same at design time and in test/preview mode.

Why, yes we were. If we change to non-draft things look much better (the fonts are too bold in GTK, but we can live with that) and the composite's subwidgets appear as if by magic.

We were all using the default designer settings BTW. Is there any reason why draft mode is the default?