August 29, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Swing from A to Z Properties, Events, and Methods

  • August 6, 2000
  • By Richard G. Baldwin
  • Send Email »
  • More Articles »


Preface

This series of lessons entitled Swing from A to Z, discusses the capabilities and features of Swing in quite a lot of detail.  This series is intended for those persons who need to really understand what Swing is all about.

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.

Introduction

One of the most important things that we can do to understand all of Swing is to learn about the properties, events, and methods that Swing components inherit from the class named JComponent and its superclasses, Container, Component, and Object.

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.

JavaBean Component Design Patterns

We can use JavaBean Component design patterns to identify properties, events, and methods of Swing components because Swing components are JavaBean Components.

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.

JComponent Properties

The properties defined in the JComponent class and its superclasses are important because they define the default behavior and appearance of most Swing components.

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.)

Container and Component Properties

Figure 2 shows the accessor methods for the properties defined in the Container and Component classes that are not overridden in the JComponent class.  Container properties are shown in blue.  Component properties are shown in red.

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.

Property Names

Although this isn't too important for this context, it might be useful for you to know how JavaBean design patterns define the names of properties.

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.

  • boolean isVisible()
  • void setVisible(boolean aFlag)
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

Another important aspect of the default behavior of most swing components is the set of standard event types that they can multicast.

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.

Container and Component Events

Figure 4 shows the event types for which registration methods are defined in the Container and Component classes.

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.

Exposed Methods of JComponent

In addition to the default behavior provided by properties and events, default behavior for many swing components is also established by the public methods of the JComponent class and its superclasses.

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.

Summary

The primary purpose of this lesson has been to provide reference information in summary form on Swing properties, events, and methods.

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.

Where To From Here?

The next several lessons will discuss and illustrate some of the common Swing properties, events, and methods listed above.


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.

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.

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.

baldwin.richard@iname.com






Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel