1.0 Introduction
2.0 Changes from the previous release
3.0 Limitations
3.1 Customed JRE Container
3.2 VAJ Visual Composition Editor code generation styles support
4.0 Known problems
4.1 Limited support for AWT menus
4.2 Limited support for Redo
4.3 SINE/Aventail conflict
4.4 Limited support for entering unicode notation
4.5 Adding properties to a this part
4.6 Single layer support for JLayeredPane
4.7 Support for launching a nonpublic class with the JavaBean launcher
4.8 Limited support for Actions
4.9 Limited support using Hummingbird Exceed 7.1
4.10 Dragging and dropping without using the mouse
4.11 No Rename field on popup of non-visuals or JMenu children
4.12 JFrame and contentPane
4.13 Singleton Support
The Visual Editor for Java is a source-centric editor that helps you design GUI applications. It is based on the JavaBeans component model and supports visual construction using either the Abstract Window Toolkit (AWT) or Swing.
If you are migrating files from the Visual Composition Editor in VisualAge for Java, top-level windows may not have the same size in this editor. The Visual Editor for Java shows the window based on the bounds or the size set in the Java code, which is the same as will be used at run-time, whereas the VisualAge for Java Visual Composition Editor used a separate size that was slightly larger.
If you use the migration utility to capture the position of free form Java beans in the VisualAge for Java Visual Composition Editor as class comments, there may be minor differences between the absolute positions used between the Visual Editor for Java and the Visual Composition Editor. This is because the Visual Composition Editor position does not take into account a non-visual Java bean's label, whereas the Visual Editor for Java does.
The Visual Editor requires either the JRE_LIB variable or the default Java JRE container to be set on a project class path in order to work properly.
These are the default entries Eclipse provides for a Java project.
The Visual Composition Editor has three styles of generating events:
Style 1: Do not use any inner classes
Style 2: Use one inner class for all events
Style 3: Use an inner class for each event
The Visual Editor for Java will recognize style 2 and style 3. If you have a class that uses style 1 you should re-generate it in style 2 before exporting it to WebSphere Studio. To change the code generation style, open the Properties for the class from its pop-up menu and select the tab "Code Generation".
The Visual Editor for Java provides limited visual support for AWT menus. The Visual Editor does provide visualization support for JMenus.
The Redo action may not fully restore an Undo action.
If you are using SINE, you must set the Aventail software to ignore java.exe in order for the Visual Editor for Java to work properly.
\uXXXX notation is not supported when entering text from the property sheet. If you need to use Unicode notation (or \t \n and so on), use the source code pane.
A this part will be created on the canvas for a class that contains properties (inherited or not). If you add properties, you will need to save the class, close it, and reopen it for the new attributes to be reflected.
The Visual Editor for Java will render JLayeredPane indexes in a single layer. In the case of multilayer / indexes, the Visual Editor for Java may not be show the components in the right order.
The JavaBean launcher does not support launching a nonpublic class.
Classes that implement the interface java.awt.Action can be added to a JMenu, JPopupMenu, and JToolBar in both the Graph viewer and Beans viewer but can only be selected, moved, and removed in the Beans viewer.
If you are using Hummingbird Exceed 7.1 as an X Server on Windows, the contentpane for a javax.swing.JFrame and other frames will not show or size correctly.
It is recommended you use a Linux X Server to work with the Visual Editor for Java.
To drop a component from the palette using the keyboard only:
Option 1: Use the source code pane.
Option 2: Use the MS accessibility tool to map the mouse to the keyboard and use as follows:A. Use the IDE keyboard shortcut to get to the tool bar (F10, and tabs), then select the ChooseBean Action with the arrow key down. From the menu items, select the component you wish to drop using the enter key.
B. Use the numeric keypad to move your loaded cursor to the area in the canvas you want to drop (you can change the location later from the source code).
C. Use the + numeric key to drop the bean.You can use the PropertySheet/source code to change the size/bound of the component.
This is a current limitation. Our rename support only shows up on visuals (that is, inherits from java.awt.Component) with the only extra restriction is that it will not show up on children or grandchildren of JMenu and JPopupMenu. Non-visuals do not have rename support at all.
The reason for this is because non-visuals currently must have ivj prefixed to their field name, otherwise they will not be found by our parser. To prevent accidently changing them and removing the ivj prefix, we make it difficult to do so. The user must go over to the Java members view and clic Refactor > Rename to do this and must be careful to keep the ivj, prefix.
The Visual Editor does not work with implicit contentPanes. It will generate code to explicitly set a JPanel as a content pane if it is not already there.
Typically it is recommended that contentPanes be generated as a seperate Bean dropped on / set as the contentPane.
The Visual Editor's Choose beans will allow one to drop JavaBeans which have null constructor in them (a JavaBean specification requirement). It will not allow one to drop Beans that use the static getInstance() pattern.
Return to the main readme file
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.