The following are frequently asked questions about Swing Designer:
Can Swing Designer edit windows created with JBuilder, VA Java, NetBeans, VisualCafe, etc.?Yes. Most GUI builders in the world will only read and write the code that they themselves create. Swing Designer 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 Swing Designer will get in the long run (and the better chance you will have of salvaging your old code as-is). Note that Swing Designer will edit any existing code in place without changing its formatting. Any new widgets will be created using Swing Designer's own code generation preferences. Can Swing Designer edit windows that have been created by hand?Yes. Most GUI builders in the world will only read and write the code that they themselves create. Swing Designer 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 Swing Designer 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. Can I refactor or otherwise modify the Swing Designer generated code?Yes. The Swing Designer parser has a good understanding of basic Java code and various Swing, SWT and other UI toolkit 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 Swing Designer will reverse engineer it when possible. You can also refactor the code in almost any conceivable way and Swing Designer 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. Why doesn't Swing Designer surround generate code with special tags or mark it as read-only?Using special tags or marking code read-only would go against several of Swing Designer's major design goals. Swing Designer does not make any distinction between generated code and user-written code. Swing Designer 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. Swing Designer 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 Swing Designer or within lines that you wrote by hand). Are there any specific constructs that Swing Designer can't parse?Yes. Here are some examples of constructs that Swing Designer does not yet handle:
Can Swing Designer use custom widgets?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 Swing Designer. Note: the Java Bean conventions 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 Swing Designer and false at runtime. What can I do if I don't see the Design tab when I edit a window?
What should I do if I encounter an exception using Swing Designer?If a newer Swing Designer 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). What should I do if I encounter "Unknown Window Type (Parsing Error)"?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). Refreshing and rebuilding your project using the Project > Clean command can often help as can cleaning your Eclipse "configuration" directory. What should I do if I encounter an OutOfMemoryError using Swing Designer?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):
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. What should I do if I encounter an NoSuchMethodError or NoClassDefFoundError using Swing Designer?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 Swing Designer loaded for the version of Eclipse you are using. Swing Designer is trying to access a method or class that simply does not exist in your Eclipse distribution. Delete the Swing Designer feature and plugin directories and then download and install the correct version of Swing Designer for the version of Eclipse you are using. What should I do if I encounter an UnsupportedClassVersionError using Swing Designer?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):
What should I do if I encounter an UnsatisfiedLinkError when launching my SWT application?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. What should I do if I encounter an InstantiationException or other error using a custom widget?An InstantiationException means that Swing Designer 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 Swing Designer and false at runtime. More detail about the use of custom widgets is available in this FAQ entry. How should Swing Designer be configured to work on Linux?To use Swing Designer 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.
You should see java pointing to the Sun JDK.
What should I do if I have problems running under SuSE Linux?If you have a problem running Swing Designer 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:
How can I prevent the preview window from flashing under Linux using MetacityIn order to create the graphics that you see in the
design view, Swing Designer 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.
|