I have a JComboBox displayed in a Panel container that is embedded in a Frame window. When I select the down arrow to make a popup window appear in order to change the selection within the entryfield, the popup window appears to be clipped. In fact, when I do some further investigation, I notice that the popup, which lists the choices to select from, appears behind the Frame component. Is this a z-order problem?
Z-order refers to how objects are layered on top of each other in a container. If an object overlays part of another control in the same container, then it is in a different layer. The layers are known as x, y, and z, thus giving us the name z-order. You can purposely set the z-order; however, I found this did not solve the problem described above. So I had to dig a little deeper.
When Java APIs were first introduced, the AWT classes consisted of mostly heavyweight objects. (One exception to this was the Component class.) The objects are heavy because they require the simultaneous creation of what is known as a peer (that is, a platform-dependent object) in order to be displayed on the screen. The peer, also known as a native window, changes based on which platform you are running on. On the other hand, most Swing classes that extend AWT do not make use of a peer object so they don’t carry the baggage that the original AWT classes do; hence the name lightweight. A lightweight component is not associated with a native opaque window. Therefore, no matter where you run your program, you will get the same look and feel, and most importantly there is no native code involved. In other words, if you use a non-Swing button, you will get a button whose look is based on the operating system (OS); whereas, if you use a Swing button, you will get a drawing of an object that appears to be a button independent of the OS. It is also important to point out that even though some of the classes make use of native OS code, this does not inhibit an application’s portability. The native code is built into the Java run-time environment, not your application.
You may have noticed that I said most Swing classes that extend AWT do not make use of a peer. JFrame does not follow this model. JFrame extends the Frame class, which is a heavyweight object. Consequently, JFrame is a heavyweight object as well. Other Swing classes that are heavyweight are JWindow, JDialog, and JApplet.
All Swing components are derived from AWT components. For example, if you travel up the hierarchical tree, you will see JLabel is derived from JComponent, which is derived from AWT Component. The AWT Component is a lightweight object so therefore, the JLabel is lightweight. Label also subclasses the Component class, so it too is considered lightweight.
The problem described above involves a Panel that is embedded in a heavyweight Frame object. The popup in the JCombobox is lightweight. Consequently, the Frame component is in the way of the JCombobox’s popup, thus hiding it in the background. The native peer window that is created with the Frame component is opaque, so it can’t be used to implement transparent areas.
table cellspacing=”0″ cellpadding=”5″ width=”30%” align=”right” border=”1″>
The JComboBox class differs from other Swing classes in that it does offer a method called setLightWeightPopupEnabled(Boolean aFlag). This method allows you make the popup a heavyweight object so that it will appear on top of a Frame window. This is the exception rather than the rule.
Now that we know what the problem is, how do we handle it? JDK 1.1 implemented the Lightweight UI Framework. The Swing classes use the Lightweight UI Framework, giving you the ability to extend the AWT Component and Container classes that do not have native opaque windows. Classes that currently subclass the heavyweight objects can adapt to this model by changing the class they subclass from.
The bottom line is that you should not mix heavyweight and lightweight objects. Follow one path or the other so that your application has a unified and consistent view across platforms. The advantages of using all lightweight objects include supporting transparent areas, the lack of additional peer classes (thus improving performance), and the ability to say that you used 100% Java code.