Editing hand-written windows
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 the tool 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.
Modifying generated code
The WindowBuilder Pro parser has a good understanding of basic Java code and various Swing and SWT 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 the tool will reverse engineer it when possible. You can also refactor the code in almost any conceivable way and the tool 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.
No special tags required
Using special tags or marking code read-only would go against several of WindowBuilder Pro's major design goals. The tool does not make any distinction between generated code and user-written code. The tool 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. The tool 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 the tool or within lines that you wrote by hand).
Specific constructs that can't be parsed
Here are some examples of constructs that the parser does not yet handle:
- Re-use of GridBagConstraint objects across multiple widgets (we support reusing the same variable but not the same objects)
- UI construction through the use of local parameterized helper methods
- Multiple aliases (fields or local variables) referring to the same component
- Multiple references to the same widget definition through multiple invocations of the same helper method
- Dynamic GUI code based on runtime calculations