Eclipse Community Forums: WindowBuilder » initDataBinding called at design time in nested composites

Home » Eclipse Projects » WindowBuilder » initDataBinding called at design time in nested composites

initDataBinding called at design time in nested composites [message #741693]

Wed, 19 October 2011 16:10

Eclipse User

We're seeing the following behavior using WindowBuilder and SWT. Sadly, we're still running Eclipse/Helios and WindowBuilder 0.9.0.r36x201102111130.

When we create a new SWT Composite using WindowBuilder and add data bindings the system creates an initDataBindings method. Normally, WindowBuilder does NOT call this method at design time.

If, however, we create a SWT Composite (with data bindings) and then drop that Composite onto another WindowBuilder created screen, the child composite's initDataBindings method is called at design time. This is something of a problem, as most of our system isn't (and shouldn't be) running then.

We've come up with several workarounds, but were wondering whether or not this is expected behavior.

I've attached a trivial sample that replicates the problem. The code has two composites: "Parent" and "Child". Each composite sets up one data binding. The "Child" contains a text box. The "Parent" contains a text box and the Child.. I've added a "System.println" to the "initDataBindings" method in both the "Parent" and "Child" classes.

If I run eclipse from the command line and open the "Parent" in design mode I get the following output:

Parsing...Child initDataBindings
done: 3327
Child initDataBindings
refresh: 137
palette: 1325

If I open the child I see:

Parsing...done: 636
refresh: 83
palette: 1058

Thanks!

-- Jim

Attachment: dbtest.tar.gz
(Size: 1.06KB, Downloaded 255 times)

Re: initDataBinding called at design time in nested composites [message #741730 is a reply to message #741693]

Wed, 19 October 2011 17:01

Eclipse User

When you drop a custom composite into another UI, it is instantiated as a live component just as any other widget would be. That means that any code reachable from the constructor will execute.

If you have code that should not run at design time, you should isolate it using a Beans.isDesignTime() check as suggested in the WindowBuilder FAQ.

Re: initDataBinding called at design time in nested composites [message #742544 is a reply to message #741730]

Thu, 20 October 2011 11:38

Eclipse User

Thanks Eric,

Using Beans.isDesignTime() was one of the options we considered. The other was to have WindowBuilder not generate the call to initDataBindings in the constructor (and for us to walk the component tree calling initDataBindings at a "good" time).

The problem with the first is that we are generating a LOT of screens and it requires a standard (and identical) manual action for each screen. We'd rather automate that if we could, as it leaves less room for errors.

The problem with the second is that is breaks the pattern that WindowBuilder uses by default and is less transparent.

A possible WindowBuilder enhancement would be to allow a little more customization of the "initDataBindings" invocation. The current system has an option to generate or not generate the call. If we generalized that to providing the actual invocation text, then we could specify something like:

if (! Beans.isDesignTime()) initDataBindings();

Such a mechanism could be rolled out as a replacement for, or an adjunct to, the current customization options. It would certainly be convenient for us.

Just a thought.

-- Jim

Re: initDataBinding called at design time in nested composites [message #742592 is a reply to message #742544]

Thu, 20 October 2011 12:23

Eclipse User

Jim Mayer wrote on Thu, 20 October 2011 11:38

A possible WindowBuilder enhancement would be to allow a little more customization of the "initDataBindings" invocation. The current system has an option to generate or not generate the call. If we generalized that to providing the actual invocation text, then we could specify something like:

if (! Beans.isDesignTime()) initDataBindings();

Such a mechanism could be rolled out as a replacement for, or an adjunct to, the current customization options. It would certainly be convenient for us.

Would there ever be a reason not to generate it that way? If not, I would suggest proposing a permanent change to the code gen (and supply a patch, if you like) on Bugzilla. I certainly don't object to a permanent code gen change like that.

Previous Topic:	WindowBuilder integration for custom table-like SWT widget
Next Topic:	Control declaration ordering

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 10:14:29 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter