http://www.developer.com/tech/article.php/629101/Swing-from-A-to-Z-Properties-Events-and-Methods.htm
Recommended supplementary reading It is recommended that in addition to studying this set of lessons, you also study my earlier lessons on Swing. A list of some of my Swing lessons can be found in an earlier lesson in this series:
Swing from A to Z: Some Simple Components
Links to the lessons themselves can be found at Baldwin's Java Programming Tutorials. The earlier lessons will introduce you to the use of Swing while avoiding much of the detail included in this series. Apply to Swing components as a group This is important because most Swing components extend JComponent either directly or indirectly. Thus, these properties, events, and methods apply to most of the components in Swing. We can learn about them as a group instead of having to learn about them on an individual component basis. Each component can have other properties, events, and methods In addition, individual Swing components can have other properties, events, and methods defined in subclasses of JComponent. We will deal with those properties, events, and methods on an individual component basis later in this series of lessons. Lesson will identify properties, events, and methods This lesson will identify the properties, events, and methods that Swing components inherit from JComponent and its superclasses. Subsequent lessons will discuss and illustrate many of them. Explained design patterns in earlier lessons I'm not going to explain design patterns here, because my earlier lessons on JavaBeans provide a complete explanation of design patterns. Rather, I am simply going to use design patterns to identify and list the properties, events, and methods of JComponent and its superclasses. If you are not familiar with Design Patterns in JavaBeans, see my earlier lessons on beans, which you will find at Baldwin's Java Programming Tutorials.
Figure 1
shows the accessor methods for the properties that are defined in the JComponent class. Inherited by most Swing components The properties in
Figure 1
are inherited by most Swing components. Some are shown in red A few of the properties are shown in red in
Figure 1
. The properties shown in red are not defined in JComponent, but rather are inherited from the Component class. They are included in
Figure 1
for completeness. In each case, they form the other half of a setter-getter method pair. (See my earlier lessons on JavaBeans if the setter-getter terminology is new to you.) Also inherited by Swing components Because JComponent extends Container, which extends Component, most of the Swing components inherit these properties as well. Hence, these properties also define the default behavior and appearance of most Swing components. Name is based on name of method The official name of a property is that portion of the name of the accessor method following set, get, or is, with the case of the first character changed to lower case. (There are also some special cases involving upper case and lower case that I won't discuss here.) A property named visible For example, the following two accessor methods refer to a property named visible. Default event types identified in JComponent and its superclasses The default event types are defined by the JComponent, Container, and Component classes. Other event types that are specific to individual Swing components may be defined in subclasses of JComponent. Event types match registration methods We can identify the default event types by identifying the event registration methods in the JComponent, Container, and Component classes. These registration methods are inherited by most Swing components. Registration method names According to JavaBean design patterns, the type of the event can be identified by the word(s) appearing between add and Listener in the name of the registration method. A PropertyChange event For example, the existence of a registration method named addPropertyChangeListener() indicates the ability to multicast an event of the PropertyChangeEvent class. The method name also indicates the availability of an interface named PropertyChangeListener. This interface must be implemented by classes from which listener objects for this type of event are instantiated. JComponent events
Figure 3
shows the event registration methods that are defined in the JComponent class. Because most Swing components extend this class, they are able to multicast events of these types. Because most Swing components extend these classes indirectly, they are able to multicast events of these types also. Events defined in the Container class are shown in blue. Events defined in the Component class are shown in red. Events familiar to AWT programmers If you are already familiar with the use of event-driven programming using the Delegation Event Model and the AWT, you should already be familiar with all but one of these event types. (If not, see my tutorial lessons on the Delegation Event Model.) One new event type The one event type that may not be familiar to you is the InputMethod event. According to one of my favorite authors, David Flanagan, "Application-level code should never have to use this class." He also states "Application-level code should never have to use or implement this interface." If you would like to know more about his reasoning, see his book entitled Java Foundation Classes in a Nutshell, published by O'Reilly. Swing components have this behavior unless they override All Swing components that extend JComponent either directly or indirectly will exhibit this default behavior unless they override the methods to provide behavior that is more appropriate for those components.
Figure 5
lists the public methods of the class JComponent that are not included in one of the previous lists. These are the public methods of the JComponent class that are not accessor methods for properties, and are not registration methods for events. Exposed methods Many Swing components expose the methods in
Figure 5
to the outside world as a result of extending the JComponent class. JavaBean introspection For example, these are the methods that a JavaBeans introspection process (based on design patterns) would consider available for invocation by other beans. Some are overridden methods Some of the methods in
Figure 5
are overridden versions of methods originally defined in Container, Component, or Object. They have been overridden to cause their behavior to be more appropriate for Swing components. Others are new methods Other methods in
Figure 5
are new methods designed to provide new behavior for Swing components. Some will be overridden later Some of the methods in
Figure 5
are overridden further down the inheritance hierarchy in the classes from which specific Swing components are instantiated. In those cases, they are overridden to make the behavior more appropriate for those specific components. Those not overridden define default behavior However, many of them are not overridden, and those that are not overridden define default behavior for many Swing components. Numerous other methods are inherited also There are numerous other methods that Swing components inherit from Container, Component, and Object and expose to the outside world. However, since they are not specific to Swing, I haven't listed them here. Will use in subsequent lessons This information will be used in subsequent lessons that discuss appearance and behavior that is common to many Swing components. Useful to understand common behavior It is useful to understand the appearance and behavior that is common to many Swing components before getting into the details of appearance and behavior that are specific to individual components. Learning the common behaviors first can greatly accelerate the learning process. Sun documentation is the final authority Please note that all of this information was extracted from the documentation for JDK 1.2.2 from Sun. Extracting the information was a tedious process, and it is possible that I may have made some mistakes. In the event of any conflict between what I have presented here and the Sun documentation, you should consider the Sun documentation to be the final authority. Copyright 2000, Richard G. Baldwin. Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited. Richard has participated in numerous consulting projects involving Java, XML, or a combination of the two. He frequently provides onsite Java and/or XML training at the high-tech companies located in and around Austin, Texas. He is the author of Baldwin's Java Programming Tutorials, which has gained a worldwide following among experienced and aspiring Java programmers. He has also published articles on Java Programming in Java Pro magazine. Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.
Swing from A to Z Properties, Events, and Methods
August 6, 2000
Preface
Introduction
JavaBean Component Design Patterns
JComponent Properties
Container and Component Properties
Property Names
You can call the first method to read the current value of the property, and you can call the second method to write a new value into the property. JComponent Events
Container and Component Events
Exposed Methods of JComponent
Summary
Where To From Here?
About the author
Richard Baldwin is a college professor and private consultant whose primary focus is a combination of Java and XML. In addition to the many platform-independent benefits of Java applications, he believes that a combination of Java and XML will become the primary driving force in the delivery of structured information on the Web.
