WindowBuilder Pro FAQ

If you encounter some sort of Eclipse Update Manager failure with messages such as "Downloaded stream not a valid archive" or "Problems downloading artifact", this is caused by a common, well known flaw in the Eclipse Update Manager with a very simple solution: wait five minutes, restart Eclipse, and try it again. Re-starting Eclipse is necessary as Eclipse will actually cache the failure and will refuse to try again during the same session. If you try this a couple of times and the problem persists, it could point to a more rare and troubling problem with a corrupted Eclipse p2 plug-in cache. The next thing to try in that case would be to re-install Eclipse and try again with a new, clean Eclipse environment. If that does not help, send a screen shot of your "Help > About > Installation Details > Installed Software" page as well as a copy of your complete "Help > About > Installation Details > Configuration" to support. You can also try installing into a new, clean Eclipse environment using one of the ZIP install options on the product download page.

Yes. Most GUI builders in the world will only read and write the code that they themselves create. WindowBuilder Pro is an exception to that rule. It can read and edit not only the code it creates, but also a great deal of code generated by other GUI builders (>95%). We have had very good success with code generated by JBuilder, NetBeans, Visual Cafe, VA Java, the Eclipse VE, etc. If you come across a case that does not work, send it to us for analysis. The more broken examples that we can "fix", the better WindowBuilder Pro will get in the long run (and the better chance you will have of salvaging your old code as-is). Note that WindowBuilder Pro will edit any existing code in place without changing its formatting. Any new widgets will be created using WindowBuilder Pro’s own code generation preferences.

Yes. Most GUI builders in the world will only read and write the code that they themselves create. WindowBuilder Pro is an exception to that rule. It can read and write not only the code it creates, but also a great deal of code written by hand(>90%). If you come across a case that does not work, send it to us for analysis. The more broken examples that we can "fix", the better WindowBuilder Pro will get in the long run (and the better chance you will have of salvaging your old code as-is).

Note that dynamic GUI code can not be rendered or edited. The problem with dynamic code is that it generally relies on runtime calculations that have no meaning at runtime. Widgets created in a loop (where the loop parameters are passed in externally) are a good example. Widgets created in conditionals where the value of the conditional is not known until runtime are another example. Dynamic GUI code constructed from the results of complex database queries is yet another example.

Yes. The WindowBuilder Pro parser has a good understanding of basic Java code and various Swing, SWT and other UI toolkit patterns patterns. As a result, it is very refactoring friendly and very resilient in the face of hand made changes. You can make changes or add code anywhere you like and WindowBuilder Pro will reverse engineer it when possible. You can also refactor the code in almost any conceivable way and WindowBuilder Pro will still be able to parse it and render it in the design view. For example, use the tool to create a new Swing JFrame, add some widgets, and then use the Eclipse refactoring tools to extract some of the widgets into their own methods.

Using special tags or marking code read-only would go against several of WindowBuilder Pro’s major design goals. WindowBuilder Pro does not make any distinction between generated code and user-written code. WindowBuilder Pro is designed to generated the same code that you would write by hand and to make minimal changes to the source when you make a change to the design view. WindowBuilder Pro never regenerates the entire source for a file. If you change a single property, it will change only a single line of code. That line of code could theoretically be anywhere in the source file (including within lines originally created by WindowBuilder Pro or within lines that you wrote by hand).

Yes. Here are some examples of constructs that WindowBuilder Pro does not yet handle:

WindowBuilder Pro can generate code into any method that you like. One of the key features of WindowBuilder Pro is its refactoring friendliness. You can actually use any template that you want for creating a new window (e.g., you don’t need to use the wizards supplied with WindowBuilder Pro). Alternatively, you can use the Eclipse refactoring commands to extract the components into a new method (like createComponents()) and the tool will continue to work. Try the following template for example:

If you start adding new widgets, they will be added to the createComponents() method.

Yes., with a few restrictions.

For Swing, any public JComponent subclass that has a public, zero-argument constructor can be used (as required by the Java Bean spec). Custom properties are derived through reflection by looking for getter/setter pairs of known types. If a matching JavaBean class is defined and available, it will be used for any custom properties. Custom JPanel subclasses will show their subcomponents when placed in WindowBuilder Pro. 

For SWT, any public Control subclass that has a public, two-argument constructor can be used (as is standard for all base SWT widgets). Custom properties are derived through reflection by looking for getter/setter pairs of known types. SWT does not yet define any kind of JavaBean interface, so no further customization is available. Custom Composite subclasses will show their subcomponents when placed in WindowBuilder Pro.

For other UI toolkits, any public Widget subclass that has a public, zero-argument constructor can be used. Custom properties are derived through reflection by looking for getter/setter pairs of known types. Custom Composite subclasses will show their subcomponents when placed in WindowBuilder Pro. 

Note: the Java Bean conventions (slightly modified for SWT) are important from a GUI builder point of view as they establish a common, expected, and, for the most part, self documenting API. If you create your own unique constructors, your are, in effect, creating your own personal API which makes it difficult for a GUI builder to reflectively interact with your components. Generating code to a custom constructor API requires knowledge of the API that generally is not provided by the component. That requires hard coding knowledge of the component into the GUI builder itself.

Note: A component may rely on some runtime behavior that is not possible at design time (such as accessing an application database or some other file). Runtime specific behavior should be isolated (and stubbed out as necessary) by wrappering the runtime specific code with a call to Beans.isDesignTime() which will answer true when the component is loaded within WindowBuilder Pro and false at runtime.

An InstantiationException means that WindowBuilder Pro could not create an instance of a particular class. The most common reason for this is that the component is not a valid custom widget. In order to be a valid Swing widget, a class must be a valid Java Bean and have a public, zero-argument constructor. SWT widgets must have a public two-argument constructor with parent and style bits as the two arguments. To fix the problem, add the missing constructor. Note: the Java Bean conventions (slightly modified for SWT) are important from a GUI builder point of view as they establish a common, expected, and, for the most part, self documenting API. If you create your own unique constructors, your are, in effect, creating your own personal API which makes it difficult for a GUI builder to reflectively interact with your components. Generating code to a custom constructor API requires knowledge of the API that generally is not provided by the component. That requires hard coding knowledge of the component into the GUI builder itself.

Another possible cause for this exception is some other failure in the initialization code of the component. A component may rely on some runtime behavior that is not possible at design time (such as accessing an application database or some other file). Runtime specific behavior should be isolated (and stubbed out as necessary) by wrappering the runtime specific code with a call to Beans.isDesignTime() which will answer true when the component is loaded within WindowBuilder Pro and false at runtime.

More detail about the use of custom widgets is available in this FAQ entry.

First, make sure that the WindowBuilder Pro plugins have been installed properly. If you used the ZIP installation, make sure that the WindowBuilder Pro plugins were unzipped to your eclipse/plugins or /dropins directory. 

If you are installing into Eclipse 3.4, there is a bug in the new p2 update manager that does not uninstall bundles (see bug 232094). To workaround this  try deleting the bundles.info file from the /configuration/org.eclipse.equinox.simpleconfigurator directory and restore the file from the Eclipse ZIP file. If deleting the bundles.info was not sufficient, delete the entire /configuration and /p2 directories from your eclipse directory and restore those directories from the Eclipse ZIP file.

After restarting Eclipse, open the Eclipse preference dialog and confirm that you see a WindowBuilder preference page. If WindowBuilder Pro still does not appear, check your Eclipse ".log" file (found in your <workspace>/.metadata directory) for any recorded exceptions and then contact support.If no exceptions are present and WindowBuilder Pro is still not present, make sure that you are using a properly configured Eclipse-based IDE. WindowBuilder Pro requires the complete Eclipse SDK to be present, and will not load into an Eclipse subset (like EasyEclipse or the MyEclipse All-in-one edition). The most important piece missing from some Eclipse distributions is the Eclipse PDE (Plug-in Development Environment). You can correct this problem by launching Eclipse and selecting Help > Software Updates. Select The Eclipse Project updates from the list of sites and select the "Eclipse Plug-in Development Environment" to install. You may need to shutdown Eclipse and clean your configuration directory as described above.

If WindowBuilder Pro fails to work properly (indicated by throwing a random exception or showing a blank design view) after installation when creating or editing a new window (or performing any simple editing activity), you are likely experiencing an installation problem. Try the following:

Eclipse remembers the last editor type used with a file. If you don’t see the Design tab, that means that you are using the standard Eclipse Java Editor rather than the WindowBuilder Editor. Open the file with the WindowBuilder Editor and you will see both the Source and Design tabs. Note that Eclipse will only let you have a file open with one editor at a time, so you may need to close any existing editor before opening it with the WindowBuilder Editor.

If a newer WindowBuilder Pro build is available than the one you are using, please download the newer build and try and reproduce the problem. If the problem has been reported in the past, there is a good chance that it has already been fixed. If the problem still exists, you should send your Eclipse ".log" file (found in your <workspace>/.metadata directory) as well as any relevant test cases to support. Including a test case that will help us reproduce the problem is very important. The faster we can reproduce the problem, the faster we can get you a fix. If we can’t reproduce a problem, there is little we can do to help you.

Ideally, the test case you send should be the same window you were editing when the problem occurred (along with any supporting files needed to compile it). If that is not possible (possibly because you aren’t allowed to send any code to a 3rd party), then you should try to create a new, standalone test case that illustrates the same problem. The best approach is to create a standalone test case by removing all of the code that isn’t relevant to the problem at hand (e.g., keep deleting code until the problem goes away and then restore that last code that was last deleted).

As suggested by the message, this is error is caused by a parsing problem. It has nothing to do with licensing. Your Eclipse ".log" file (found in your <workspace>/.metadata directory) should provide a hint as to the cause of the parsing error. Send the log file as well as a test case to support (ideally the window you are trying to edit). Including a test case that will help us reproduce the problem is very important. The faster we can reproduce the problem, the faster we can get you a fix. If we can’t reproduce a problem, there is little we can do to help you.

Ideally, the test case you send should be the same window you were editing when the problem occurred (along with any supporting files needed to compile it). If that is not possible (possibly because you aren’t allowed to send any code to a 3rd party), then you should try to create a new, standalone test case that illustrates the same problem. The best approach is to create a standalone test case by removing all of the code that isn’t relevant to the problem at hand (e.g., keep deleting code until the problem goes away and then restore that last code that was last deleted).

Parsing problems can also be a side effect of the other problems described in the earlier FAQ entry here so check each of the suggestions there. Refreshing and rebuilding your project using the Project > Clean command can often help as can cleaning your Eclipse "configuration" directory.

Make sure that you have Eclipse configured to use enough memory. Begin by specifying the starting amount of memory (-vmargs -Xms###m) in your Eclipse startup command line (e.g., the target field within a Windows shortcut) or eclipse.ini file (in your Eclipse root directory). If this is not specified, Eclipse’s starting amount of memory is quite small (only 40 MB). You should also specify the maximum amount of memory that Eclipse can use (-vmargs -Xmx###m) and the maximum amount of perm space available (-vmargs -XX:MaxPermSize=###m).

We typically recommend something like this (these setting are independent of any of the startup settings that you might have in place):

-vmargs -XX:MaxPermSize=128m -Xms256m -Xmx512m

An OutOfMemoryError is usually a side effect of something else, so you should send your Eclipse ".log" file (found in your <workspace>/.metadata directory) as well as any relevant test cases to support.

You might try running Eclipse with the -debug command line option. You can then press Ctrl+Break in the console to look at the thread dump which may show where the system is locking up and where the memory is going. Send that thread dump to support

Start by checking your Eclipse ".log" file (found in your <workspace>/.metadata directory). If the error references one of your classes or methods, check that your classpath properly references the class you are trying to use. Also check that your class is properly compiled (no red X's) and that a .class file exists in your projects /bin directory. A mismatch between the JDK used to compile your code and the JVM used to run Eclipse can also manifest itself as a NoClassDefFoundError problem. For example, if you compile your code using JDK 1.5 or 1.6 and then run your Eclipse using a 1.4 or 1.5 JVM, you can have this problem. If the error refers to a custom widget, you should also check that your component does not trigger an exception during its initialization (which can manifest itself as a NoClassDefFoundError). Try refreshing and cleaning your project using the Project > Clean…​ or Project > Build Project commands. If that does not help, send a test case to support.

If the error references a base Eclipse method or class, this means that you have the wrong version of WindowBuilder Pro loaded for the version of Eclipse you are using. WindowBuilder Pro is trying to access a method or class that simply does not exist in your Eclipse distribution. Delete the WindowBuilder Pro feature and plugin directories and then download and install the correct version of  WindowBuilder Pro for the version of Eclipse you are using.

If the error refers to a method or class in a WindowBuilder Pro class, this means that you have a serious Eclipse configuration problem, and that one or more of the WindowBuilder Pro plugins are not being loaded properly. If a plugin does not load, all of its methods will be unreachable, and any attempts to access them will trigger a NoSuchMethodError or NoClassDefFoundError. This problem can usually be fixed by cleaning your Eclipse "configuration" directory as described in this earlier FAQ entry.

An UnsupportedClassVersionError is usually caused by attempting to run code compiled against a later JRE with an IDE using an earlier JRE. Typically, you will see this when trying to use a class (such as a custom widget) that has been compiled against JDK 1.6 within a version of Eclipse launched with JDK 1.5.

Two solutions are possible: you may either recompile the class using JDK 1.5, or you can tell Eclipse to run using JDK 1.6 by modifying its startup parameters as follows (use your path to JDK 1.6 on your system):

As stated in the product docs and tutorial, the Eclipse SWT DLL (which can be found in the $ECLIPSE$\plugins\org.eclipse.swt.win32_x.x.x\os\win32\x86\ directory or in the org.eclipse.swt.win32.win32.x86_3.x.x.jar file) needs to be on your path. Placing it into your windows/system32 directory is the easiest thing to do.

For Linux, you need to locate the corresponding Eclipse SWT *.so files contained in the SWT GTK plugin.

To use WindowBuilder Pro in Linux, we recommend that you use an official JDK from Sun, as using the GPL version of the java is not recommended. Here are some setup instructions for using Sun’s java with Fedora Core and Debian. Note that use of a non-Sun JDK can result in Eclipse locking up.

Using Sun’s Java with Fedora Core:

You should see java pointing to the Sun JDK.

Using Sun’s Java with Debian:

If you have a problem running WindowBuilder Pro on Linux SuSE 10.3 such as Eclipse crashing and/or working incorrectly, or your my log files contains something like "xcb_xlib.c:42: xcb_xlib_lock: Assertion `!c→xlib.lock'" and/or "/usr/lib/Eclipse: No such file or directory", please try to add the following into you profile:

In order to create the graphics that you see in the design view, WindowBuilder Pro creates an off screen window containing the various widgets and they takes a screen snapshot of them. This works very well under Windows, OSX and some versions of Linux. Recent versions of the Metacity window manager (more recent than 2.1.4), however, have been modified/"fixed" to disallow windows to be opened off screen. This forces the preview window to appear on screen leading to an annoying flashing effect any time you make a change. The solution is to disable the Metacity "fully_onscreen" constraint by patching the Metacity source code and rebuilding and installing the patched version into your system.

Here are the steps to follow: