For Java 2 platform v1.3, a KeyStroke can be associated with more than one condition. For example, 'a' could be bound for the two conditions WHEN_FOCUSED and WHEN_IN_FOCUSED_WINDOW condition.

• JScrollPane.LOWER_LEFT_CORNER
• JScrollPane.LOWER_RIGHT_CORNER
• JScrollPane.UPPER_LEFT_CORNER
• JScrollPane.UPPER_RIGHT_CORNER
• JScrollPane.LOWER_LEADING_CORNER
• JScrollPane.LOWER_TRAILING_CORNER
• JScrollPane.UPPER_LEADING_CORNER
• JScrollPane.UPPER_TRAILING_CORNER

If a Set of traversal keys has not been explicitly defined for this Container, then this Container's parent's Set is returned. If no Set has been explicitly defined for any of this Container's ancestors, then the current KeyboardFocusManager's default Set is returned.

You can specify the listenerType argument with a class literal, such as FooListener.class. For example, you can query a JComponent c for its mouse listeners with the following code:

MouseListener[] mls = (MouseListener[])(c.getListeners(MouseListener.class));

Due to the asynchronous nature of native event handling, this method can return outdated values (for instance, after several calls of setLocation() in rapid succession). For this reason, the recommended method of obtaining a component's position is within java.awt.event.ComponentListener.componentMoved(), which is called after the operating system has finished moving the component.

For Containers it returns a non-null value if the mouse is above the Container itself or above any of its descendants. Use if you need to exclude children.

Sometimes the exact mouse coordinates are not important, and the only thing that matters is whether a specific Component is under the mouse pointer. If the return value of this method is null, mouse pointer is not directly above the Component.

Returns the Component set by a prior call to setNextFocusableComponent(Component) on this JComponent.

This method is intended for use by focus implementations. Client code should not use this method; instead, it should use requestFocusInWindow().

The general contract of hashCode is:

• Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
• If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
• It is not required that if two objects are unequal according to the method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java^TM programming language.)

The imageUpdate method of Component incrementally draws an image on the component as more of the bits of the image are available.

If the system property awt.image.incrementaldraw is missing or has the value true, the image is incrementally drawn. If the system property has any other value, then the image is not drawn until it has been completely loaded.

Also, if incremental drawing is in effect, the value of the system property awt.image.redrawrate is interpreted as an integer to give the maximum redraw rate, in milliseconds. If the system property is missing or cannot be interpreted as an integer, the redraw rate is once every 100ms.

The interpretation of the x, y, width, and height arguments depends on the value of the infoflags argument.

A component is made displayable either when it is added to a displayable containment hierarchy or when its containment hierarchy is made displayable. A containment hierarchy is made displayable when its ancestor window is either packed or made visible.

A component is made undisplayable either when it is removed from a displayable containment hierarchy or when its containment hierarchy is made undisplayable. A containment hierarchy is made undisplayable when its ancestor window is disposed.

This method will always return false if this component is not displayable because it is impossible to determine the weight of an undisplayable component.

Changes this JComponent's focus traversal keys to CTRL+TAB and CTRL+SHIFT+TAB. Also prevents SortingFocusTraversalPolicy from considering descendants of this JComponent when computing a focus traversal cycle.

An opaque component paints every pixel within its rectangular bounds. A non-opaque component paints only a subset of its pixels or none at all, allowing the pixels underneath it to "show through". Therefore, a component that does not fully paint its pixels provides a degree of transparency.

Subclasses that guarantee to always completely paint their contents should override this method and return true.

Please see How to Use the Focus Subsystem, a section in The Java Tutorial, for more information.

The immediate children of the container are printed with an indentation of indent+1. The children of those children are printed at indent+2 and so on.

The immediate children of the container are printed with an indentation of indent+1. The children of those children are printed at indent+2 and so on.

The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.

This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:

• By executing a synchronized instance method of that object.
• By executing the body of a synchronized statement that synchronizes on the object.
• For objects of type Class, by executing a synchronized static method of that class.

Only one thread at a time can own an object's monitor.

The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.

This method should only be called by a thread that is the owner of this object's monitor. See the notify method for a description of the ways in which a thread can become the owner of a monitor.

This method actually delegates the work of painting to three protected methods: paintComponent, paintBorder, and paintChildren. They're called in the order listed to ensure that children appear on top of component itself. Generally speaking, the component and its children should not paint in the insets area allocated to the border. Subclasses can just override this method, as always. A subclass that just wants to specialize the UI (look and feel) delegate's paint method should just override paintComponent.

The origin of the graphics context, its (0, 0) coordinate point, is the top-left corner of this component. The clipping region of the graphics context is the bounding rectangle of this component.

It's rarely necessary to call this method. In most cases it's more efficient to call repaint, which defers the actual painting and can collapse redundant requests into a single paint call. This method is useful if one needs to update the display while the current event is being dispatched.

The image data is downloaded asynchronously in another thread, and an appropriately scaled screen representation of the image is generated.

The get/putClientProperty methods provide access to a small per-instance hashtable. Callers can use get/putClientProperty to annotate components that were created by another module. For example, a layout manager might store per child constraints this way. For example:

 componentA.putClientProperty("to the left of", componentB);
 

The clientProperty dictionary is not intended to support large scale extensions to JComponent nor should be it considered an alternative to subclassing when designing a new component.

   component.getInputMap().put(aKeyStroke, aCommand);
   component.getActionMap().put(aCommmand, anAction);
 

Register a new keyboard action. anAction will be invoked if a key event matching aKeyStroke occurs and aCondition is verified. The KeyStroke object defines a particular combination of a keyboard key and one or more modifiers (alt, shift, ctrl, meta).

The aCommand will be set in the delivered event if specified.

The aCondition can be one of:

WHEN_FOCUSED

The action will be invoked only when the keystroke occurs while the component has the focus.

WHEN_IN_FOCUSED_WINDOW

The action will be invoked when the keystroke occurs while the component has the focus or if the component is in the window that has the focus. Note that the component need not be an immediate descendent of the window -- it can be anywhere in the window's containment hierarchy. In other words, whenever any component in the window has the focus, the action registered with this component is invoked.

WHEN_ANCESTOR_OF_FOCUSED_COMPONENT

The action will be invoked when the keystroke occurs while the component has the focus or if the component is an ancestor of the component that has the focus.

The combination of keystrokes and conditions lets you define high level (semantic) action events for a specified keystroke+modifier combination (using the KeyStroke class) and direct to a parent or child of a component that has the focus, or to the component itself. In other words, in any hierarchical structure of components, an arbitrary key-combination can be immediately directed to the appropriate component in the hierarchy, and cause a specific method to be invoked (usually by way of adapter objects).

If an action has already been registered for the receiving container, with the same charCode and the same modifiers, anAction will replace the action.

If listener is null, no exception is thrown and no action is performed.

If propertyName or listener is null, no exception is thrown and no action is taken.

If this component is a lightweight component, this method causes a call to this component's paint method as soon as possible. Otherwise, this method causes a call to this component's update method as soon as possible.

Note: For more information on the paint mechanisms utilitized by AWT and Swing, including information on how to write the most efficient painting code, see Painting in AWT and Swing.

If this component is a lightweight component, this method causes a call to this component's paint method as soon as possible. Otherwise, this method causes a call to this component's update method as soon as possible.

Note: For more information on the paint mechanisms utilitized by AWT and Swing, including information on how to write the most efficient painting code, see Painting in AWT and Swing.

Note: For more information on the paint mechanisms utilitized by AWT and Swing, including information on how to write the most efficient painting code, see Painting in AWT and Swing.

Requests focus on this JComponent's FocusTraversalPolicy's default Component. If this JComponent is a focus cycle root, then its FocusTraversalPolicy is used. Otherwise, the FocusTraversalPolicy of this JComponent's focus-cycle-root ancestor is used.

Note that the use of this method is discouraged because its behavior is platform dependent. Instead we recommend the use of requestFocusInWindow() . If you would like more information on focus, see

Note that the use of this method is discouraged because its behavior is platform dependent. Instead we recommend the use of requestFocusInWindow(boolean) . If you would like more information on focus, see How to Use the Focus Subsystem, a section in The Java Tutorial.

If you would like more information on focus, see How to Use the Focus Subsystem, a section in The Java Tutorial.

Calls invalidate and then adds this component's validateRoot to a list of components that need to be validated. Validation will occur after all currently pending events have been dispatched. In other words after this method is called, the first validateRoot (if any) found when walking up the containment hierarchy of this component will be validated. By default, JRootPane, JScrollPane, and JTextField return true from isValidateRoot.

This method will automatically be called on this component when a property value changes such that size, location, or internal layout of this component has been affected. This automatic updating differs from the AWT because programs generally no longer need to invoke validate to get the contents of the GUI to update.

 MouseMotionListener doScrollRectToVisible = new MouseMotionAdapter() {
     public void mouseDragged(MouseEvent e) {
        Rectangle r = new Rectangle(e.getX(), e.getY(), 1, 1);
        ((JPanel)e.getSource()).scrollRectToVisible(r);
    }
 };
 myPanel.addMouseMotionListener(doScrollRectToVisible);
 

Although technically you can set the border on any object that inherits from JComponent, the look and feel implementation of many standard Swing components doesn't work well with user-set borders. In general, when you want to set a border on a standard Swing component other than JPanel or JLabel, we recommend that you put the component in a JPanel and set the border on the JPanel.

This is a bound property.