Source code generated and parsed by the visual editor
There are different styles or ways for writing Java code. The visual editor uses a particular style for its generated Java code.
The visual editor for Java generates valid Java code that can be properly compiled and run. In addition, when the visual editor parses existing Java code, it uses rules to determine which elements of the code to try to visualize in the Design view.
Rules for parsable code
The visual editor for Java attempts to visualize code in the Design view if the code meets any of the following criteria:
- The component is a visual class. Visual classes are subclasses of java.awt.Component or org.eclipse.swt.widgets.Widget. These are already modeled by the visual editor.
- The declaration includes a // @jve: parse annotation. When you drop a non-visual component onto the Design view, the visual editor generates an annotation that says the code should be parsed by the visual editor. An example of a full annotation looks like this:
// @jve:decl-index=0:parse,visual-constraint="201,92"If you type your own Java code for a non-visual component and you want it to be included on the Design view, be sure to include an annotation similar to this.- The field name begins with the letters ivj. This rule exists to satisfy existing legacy code.
There are other requirements that the visual editor checks before visualizing a component on the graphical Design view:
- Fields must be instantiated within a get method, or the bean must be initialized by an initialization method that is listed on the Pattern Styles tab of the visual editor Preferences page. Notice in the following image that the jbInit, initComponents, and initialize methods are specified as initialization methods:
- There must not be a compilation error on the line.
- A class must be valid to load and instantiate
- Most array initialization expressions cannot be evaluated
- Expressions that involve arithmetic or string concatenation using the + operand will be not be evaluated
Most expressions are successfully parsed, but not all expressions can be correctly evaluated. In this case a warning sign will be shown against the Java bean in the views, and the reason for the failure will be shown in the status line when the bean is selected on the Design view or Java Beans view. A warning icon will also display on the canvas.
Code generated by the visual editor
- The visual editor generates default constructors that call the method initialize(), which sets the values of the properties for the class.
- For applets, the code to set the initial property values is called init(). This is not called by the constructor, as it will be executed by the applet browser itself.
- Optional: You can specify that the visual editor generate try{}catch() blocks for components. This will continuously catch every exception thrown during initialization, and the the risk of exceptions being suppressed could increase. Therefore, it is better to let the exception pass through instead. You can select this option on the Code Generation tab of the visual editor preferences (Window > Preferences > Java > Visual Editor). The following code shows a JPanel initialized with the try{}catch() block:
private JPanel getJPanel1() { if (jPanel1 == null) { try { jPanel1 = new JPanel(); } catch (java.lang.Throwable e) { // TODO: Something } } return jPanel1; }The following code shows a JPanel without the try{}catch() block of code:private JPanel getJPanel() { if (jPanel == null) { jPanel = new JPanel(); } return jPanel; }- Optional: You can also specify that the visual editor add a comment marking each expression that it generates. This could be useful for distinguishing hand-written code from generated code. The following line of code is an example of what the comment looks like:
this.add(getJPanel(), null); // GeneratedTo turn on this option, select the Generate a comment for new expressions check box on the on the Code Generation tab of the visual editor preferences.- For Swing/AWT, although the visual editor generates methods such as getPanel() that instantiate and return a single Java bean, this is not a requirement. A method can instantiate more than one Java bean, and the return value of the method is not important for recognizing whether the field is a Java bean. For the fields anOKButton and ivjTableModel to be included as Java beans, they will need to be instantiated within a get method in the class.
- For SWT, the visual editor generates private void createFoo() methods for every class extending Composite, and any children beans are initialized within the same method.
- If the edited class extends a Java bean, the instance being edited is represented with a special Java bean called a 'this' part. The 'this' part cannot be deleted from the Design view or Java Beans view, and the initialization method for its properties are done in the initialize() method. A 'this' part is only shown in the Design view and Java Beans view if there are any properties that are available to set on the Properties view. The set methods for the properties are generated in the initialize() method, or if the class extends java.awt.Applet the init() method is used.
Parent topic
Source code generation in the visual editor