Brought to you by EarthWeb
ITKnowledge Logo Login Graphic Click Here!
Click Here!
ITKnowledge
Find:
 
EXPERT SEARCH ----- nav

EarthWeb Direct

EarthWeb Direct

EarthWeb sites: other sites

Previous Table of Contents Next


Chapter 3
JComponent

In This Chapter
•  Top of the JFC Visual Component Hierarchy
•  Client Properties
•  ToolTip Support
•  Border Property
•  Size Preferences
•  Keystroke Handling
•  Scrolling Support
•  Focus Transversal Support
•  Property Listener Support
•  Pluggable Look-and-Feel Support
•  Miscellaneous Features

The JComponent class is the root of the visual component class hierarchy in the JFC. The visual components are known as the “J” classes. This is because each of the class names begins with the letter J. As such, the functionality contained in the JComponent class is available to all the visual components contained in the JFC. The JComponent class turns into a repository of functionality required for all visual components. This includes key-stroke handling, accessibility support, borders, and much more. This common functionality makes the JComponent class a large and complex one that must be thoroughly understood to take full advantage of the JFC toolkit. A hint of the complexity and sheer size of the JComponent class is the approximately 30 javadoc pages for the class that accompany the JFC toolkit.

This chapter will dissect the JComponent class, looking at each segment of its functionality individually. Specifically, you will see the following:

  The visual class hierarchy
  Pluggable look-and-feel support in JComponent
  Keystroke handling in JComponent
  The Border property
  Scrolling support
  Accessibility support
  Internationalization support

Top of the JFC Visual Component Hierarchy

The JComponent class sits atop the hierarchy of the visual classes contained in the JFC. This hierarchy is shown in Figure 3.1. Its position in the hierarchy implies that its functionality is common to all visual components in the JFC toolkit. This makes understanding the JComponent class critical to taking full advantage of the JFC toolkit.


Figure 3.1  JFC visual component class hierarchy.

The JComponent class is an abstract class that extends the AWT Container class. The Container class extends the AWT Component class. In the AWT, there is a distinction between components that are containers and those that are not. For example, the AWT Label class extends Component. As such, other components cannot be added to instances of the Label class. However, the AWT Panel class extends the Container class, which does allow components to be added to it. Thus, the position in the class hierarchy defines if a class can act as a container or not. With the JComponent class extending the Component class, this distinction doesn’t exist in the JFC. Thus, every JComponent is a container, even though many are not designed to be used as such. This forces those classes to carry the extra baggage of being a container, even though it is not used. This is an unfortunate consequence of the JFC being layered on top of the AWT. Most, if not all, of the functionality contained in the JComponent class would be better suited in the Component class.

Client Properties

A client property is a piece of information that can be attached to an instance of any JFC visual component. The property consists of a name-value pair. The name is a key that uniquely identifies the value for a particular instance. Internally, client properties are implemented as a Dictionary, specifically an instance of the HashTable class. Client properties are used internally by the JFC in many situations. For example, a component’s ToolTip, keyboard bindings, and the next focus component are all stored as client properties on a component.

Client properties are not limited to use within the JFC itself. Components that extend JFC visual components can store data in client properties as well as arbitrary code that creates and uses instances of JFC visual components. The former will be discussed in Part V of this book, “Extending JFC Components,” while the later will be discussed here.

An arbitrary Object can be associated with a JFC visual component instance by using the putClientProperty method contained in the JComponent class. When the property is placed on the component, a key is associated with the object. The client property can be obtained later via the getClientProperty method and the key used when adding the property. A simple example of using a client property is shown in the following:

JButton button = new JButton( “Help” );
button.putClientProperty( “SpecialColor”, Color.blue );
Color myColor = ( Color )button.getClientProperty( “SpecialColor” );

This example adds a client property with the String key “SpecialColor” to an instance of the JButton class. In this example, a string is used as the key, but an arbitrary object can be used as the key. The property in the example is a Color but, like the key, the property can be of any type. If the property value is null in the putClientProperty call, the property is removed from the instance. However, null cannot be used as the key. If this occurs, a NullPointerException is thrown. The getClientProperty method returns the object associated with the given key for the instance. If there has not been an object associated with the key, null is returned. Any number of client properties can be added to a component. However, each property must have a unique key.

When a client property is set, a PropertyChange event is fired by the component that contains the property. The name of the property change event is the value returned from the toString method key used to store the client property. This provides a very versatile mechanism for attaching data to a visual component and allowing other objects to listen for changes in this property.


Previous Table of Contents Next
HomeAbout UsSearchSubscribeAdvertising InfoContact UsFAQs
Use of this site is subject to certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.