Java Tutorial & Books Download

Component

2008-05-12T03:38:00.000-07:00

java.awt
Class Component

java.lang.Object
 java.awt.Component

A component is an object having a graphical representation that can be displayed on the screen and that can interact with the user. Examples of components are the buttons, checkboxes, and scrollbars of a typical graphical user interface.

The Component class is the abstract superclass of the nonmenu-related Abstract Window Toolkit components. Class Component can also be extended directly to create a lightweight component. A lightweight component is a component that is not associated with a native opaque window.

SystemColor

2008-05-12T03:37:00.000-07:00

java.awt
Class SystemColor

java.lang.Object
 java.awt.Color
     java.awt.SystemColor


A class to encapsulate symbolic colors representing the color of
native GUI objects on a system.  For systems which support the dynamic
update of the system colors (when the user changes the colors)
the actual RGB values of these symbolic colors will also change
dynamically.  In order to compare the "current" RGB value of a
SystemColor object with a non-symbolic Color object,
getRGB should be used rather than equals.

Class Color

2008-05-12T03:36:00.002-07:00

java.awt
Class Color

java.lang.Object
java.awt.Color


The Color class is used to encapsulate colors in the default
sRGB color space or colors in arbitrary color spaces identified by a
ColorSpace.  Every color has an implicit alpha value of 1.0 or
an explicit one provided in the constructor.  The alpha value
defines the transparency of a color and can be represented by
a float value in the range 0.0 - 1.0 or 0 - 255.
An alpha value of 1.0 or 255 means that the color is completely
opaque and an alpha value of 0 or 0.0 means that the color is
completely transparent.
When constructing a Color with an explicit alpha or
getting the color/alpha components of a Color, the color
components are never premultiplied by the alpha component.

CheckboxGroup

2008-05-12T03:36:00.001-07:00

java.awt
Class CheckboxGroup

java.lang.Object
 java.awt.CheckboxGroup

The CheckboxGroup class is used to group together a set of Checkbox buttons.

Exactly one check box button in a CheckboxGroup can be in the "on" state at any given time. Pushing any button sets its state to "on" and forces any other button that is in the "on" state into the "off" state.

CardLayout

2008-05-12T03:35:00.001-07:00

java.awt
Class CardLayout

java.lang.Object
 java.awt.CardLayout

A CardLayout object is a layout manager for a container. It treats each component in the container as a card. Only one card is visible at a time, and the container acts as a stack of cards. The first component added to a CardLayout object is the visible component when the container is first displayed.

The ordering of cards is determined by the container's own internal ordering of its component objects. CardLayout defines a set of methods that allow an application to flip through these cards sequentially, or to show a specified card. The addLayoutComponent(java.awt.Component, java.lang.Object) method can be used to associate a string identifier with a given card for fast random access.

Component.FlipBufferStrategy

2008-05-05T18:35:00.000-07:00

java.awt
Class Component.FlipBufferStrategy

java.lang.Object
 java.awt.image.BufferStrategy
     java.awt.Component.FlipBufferStrategy

protected class Component.FlipBufferStrategy
extends BufferStrategy
extends BufferStrategy

Inner class for flipping buffers on a component. That component must be a Canvas or Window.

Component.BltBufferStrategy

2008-05-05T18:34:00.000-07:00

java.awt
Class Component.BltBufferStrategy

java.lang.Object
 java.awt.image.BufferStrategy
     java.awt.Component.BltBufferStrategy

protected class Component.BltBufferStrategy
extends BufferStrategy
extends BufferStrategy

Inner class for blitting offscreen surfaces to a component.

BufferStrategy

2008-05-05T18:33:00.000-07:00

java.awt.image
Class BufferStrategy

java.lang.Object
 java.awt.image.BufferStrategy

public abstract class BufferStrategy
extends Object
extends Object

The BufferStrategy class represents the mechanism with which to organize complex memory on a particular Canvas or Window. Hardware and software limitations determine whether and how a particular buffer strategy can be implemented. These limitations are detectible through the capabilities of the GraphicsConfiguration used when creating the Canvas or Window.

It is worth noting that the terms buffer and surface are meant to be synonymous: an area of contiguous memory, either in video device memory or in system memory.

There are several types of complex buffer strategies; sequential ring buffering, blit buffering, and stereo buffering are common types. Sequential ring buffering (i.e., double or triple buffering) is the most common; an application draws to a single back buffer and then moves the contents to the front (display) in a single step, either by copying the data or moving the video pointer. Moving the video pointer exchanges the buffers so that the first buffer drawn becomes the front buffer, or what is currently displayed on the device; this is called page flipping.

Alternatively, the contents of the back buffer can be copied, or blitted forward in a chain instead of moving the video pointer.

Double buffering: *********** *********** * * ------> * * [To display] <---- * Front B * Show * Back B. * <---- Rendering * * <------ * * *********** *********** Triple buffering: [To *********** *********** *********** display] * * --------+---------+------> * * <---- * Front B * Show * Mid. B. * * Back B. * <---- Rendering * * <------ * * <----- * * *********** *********** ***********

Stereo buffering is for hardware that supports rendering separate images for a left and right eye. It is similar to sequential ring buffering, but there are two buffer chains, one for each eye. Both buffer chains flip simultaneously:

Stereo buffering: *********** *********** * * ------> * * [To left eye] <---- * Front B * * Back B. * <---- Rendering * * <------ * * *********** *********** Show *********** *********** * * ------> * * [To right eye] <--- * Front B * * Back B. * <---- Rendering * * <------ * * *********** ***********

BufferCapabilities.FlipContents

2008-05-05T18:32:00.000-07:00

java.awt
Class BufferCapabilities.FlipContents

java.lang.Object
 java.awt.BufferCapabilities.FlipContents

public static final class BufferCapabilities.FlipContents
extends Object
extends Object

A type-safe enumeration of the possible back buffer contents after page-flipping

BufferCapabilities

2008-05-05T18:31:00.000-07:00

java.awt
Class BufferCapabilities

java.lang.Object
 java.awt.BufferCapabilities

public class BufferCapabilities
extends Object
implements Cloneable
extends Object
implements Cloneable

Capabilities and properties of buffers.

BorderLayout

2008-05-05T18:30:00.000-07:00

java.awt
Class BorderLayout

java.lang.Object
 java.awt.BorderLayout

public class BorderLayout
extends Object
implements LayoutManager2, Serializable
extends Object
implements LayoutManager2, Serializable

A border layout lays out a container, arranging and resizing its components to fit in five regions: north, south, east, west, and center. Each region may contain no more than one component, and is identified by a corresponding constant: NORTH, SOUTH, EAST, WEST, and CENTER. When adding a component to a container with a border layout, use one of these five constants, for example:

Panel p = new Panel(); p.setLayout(new BorderLayout()); p.add(new Button("Okay"), BorderLayout.SOUTH); As a convenience, BorderLayout interprets the absence of a string specification the same as the constant CENTER: Panel p2 = new Panel(); p2.setLayout(new BorderLayout()); p2.add(new TextArea()); // Same as p.add(new TextArea(), BorderLayout.CENTER);

In addition, BorderLayout supports the relative positioning constants, PAGE_START, PAGE_END, LINE_START, and LINE_END. In a container whose ComponentOrientation is set to ComponentOrientation.LEFT_TO_RIGHT, these constants map to NORTH, SOUTH, WEST, and EAST, respectively.

For compatibility with previous releases, BorderLayout also includes the relative positioning constants BEFORE_FIRST_LINE, AFTER_LAST_LINE, BEFORE_LINE_BEGINS and AFTER_LINE_ENDS. These are equivalent to PAGE_START, PAGE_END, LINE_START and LINE_END respectively. For consistency with the relative positioning constants used by other components, the latter constants are preferred.

Mixing both absolute and relative positioning constants can lead to unpredicable results. If you use both types, the relative constants will take precedence. For example, if you add components using both the NORTH and PAGE_START constants in a container whose orientation is LEFT_TO_RIGHT, only the PAGE_START will be layed out.

NOTE: Currently (in the Java 2 platform v1.2), BorderLayout does not support vertical orientations. The isVertical setting on the container's ComponentOrientation is not respected.

The components are laid out according to their preferred sizes and the constraints of the container's size. The NORTH and SOUTH components may be stretched horizontally; the EAST and WEST components may be stretched vertically; the CENTER component may stretch both horizontally and vertically to fill any space left over.

BasicStroke

2008-05-05T18:29:00.000-07:00

java.awt
Class BasicStroke

java.lang.Object
 java.awt.BasicStroke

The BasicStroke class defines a basic set of rendering attributes for the outlines of graphics primitives, which are rendered with a Graphics2D object that has its Stroke attribute set to this BasicStroke. The rendering attributes defined by BasicStroke describe the shape of the mark made by a pen drawn along the outline of a Shape and the decorations applied at the ends and joins of path segments of the Shape. These rendering attributes include:

width: The pen width, measured perpendicularly to the pen trajectory.
end caps: The decoration applied to the ends of unclosed subpaths and dash segments. Subpaths that start and end on the same point are still considered unclosed if they do not have a CLOSE segment. See SEG_CLOSE for more information on the CLOSE segment. The three different decorations are: CAP_BUTT, CAP_ROUND, and CAP_SQUARE.
line joins: The decoration applied at the intersection of two path segments and at the intersection of the endpoints of a subpath that is closed using SEG_CLOSE. The three different decorations are: JOIN_BEVEL, JOIN_MITER, and JOIN_ROUND.
miter limit: The limit to trim a line join that has a JOIN_MITER decoration. A line join is trimmed when the ratio of miter length to stroke width is greater than the miterlimit value. The miter length is the diagonal length of the miter, which is the distance between the inside corner and the outside corner of the intersection. The smaller the angle formed by two line segments, the longer the miter length and the sharper the angle of intersection. The default miterlimit value of 10.0f causes all angles less than 11 degrees to be trimmed. Trimming miters converts the decoration of the line join to bevel.
dash attributes: The definition of how to make a dash pattern by alternating between opaque and transparent sections.

All attributes that specify measurements and distances controlling the shape of the returned outline are measured in the same coordinate system as the original unstroked Shape argument. When a Graphics2D object uses a Stroke object to redefine a path during the execution of one of its draw methods, the geometry is supplied in its original form before the Graphics2D transform attribute is applied. Therefore, attributes such as the pen width are interpreted in the user space coordinate system of the Graphics2D object and are subject to the scaling and shearing effects of the user-space-to-device-space transform in that particular Graphics2D. For example, the width of a rendered shape's outline is determined not only by the width attribute of this BasicStroke, but also by the transform attribute of the Graphics2D object. Consider this code:

// sets the Graphics2D object's Tranform attribute g2d.scale(10, 10); // sets the Graphics2D object's Stroke attribute g2d.setStroke(new BasicStroke(1.5f));

Assuming there are no other scaling transforms added to the Graphics2D object, the resulting line will be approximately 15 pixels wide. As the example code demonstrates, a floating-point line offers better precision, especially when large transforms are used with a Graphics2D object. When a line is diagonal, the exact width depends on how the rendering pipeline chooses which pixels to fill as it traces the theoretical widened outline. The choice of which pixels to turn on is affected by the antialiasing attribute because the antialiasing rendering pipeline can choose to color partially-covered pixels.

For more information on the user space coordinate system and the rendering process, see the Graphics2D class comments.

AWTKeyStroke

2008-05-05T18:28:00.000-07:00

java.awt
Class AWTKeyStroke

java.lang.Object
 java.awt.AWTKeyStroke

public class AWTKeyStroke
extends Object
implements Serializable
extends Object
implements Serializable

An AWTKeyStroke represents a key action on the keyboard, or equivalent input device. AWTKeyStrokes can correspond to only a press or release of a particular key, just as KEY_PRESSED and KEY_RELEASED KeyEvents do; alternately, they can correspond to typing a specific Java character, just as KEY_TYPED KeyEvents do. In all cases, AWTKeyStrokes can specify modifiers (alt, shift, control, meta, or a combination thereof) which must be present during the action for an exact match.

AWTKeyStrokes are immutable, and are intended to be unique. Client code should never create an AWTKeyStroke on its own, but should instead use a variant of getAWTKeyStroke. Client use of these factory methods allows the AWTKeyStroke implementation to cache and share instances efficiently.

Interface InputMethodListener

2008-05-05T18:27:00.001-07:00

java.awt.event
Interface InputMethodListener

he listener interface for receiving input method events. A text editing component has to install an input method event listener in order to work with input methods.

The text editing component also has to provide an instance of InputMethodRequests.

Interface ContainerListener

2008-05-05T18:26:00.000-07:00

java.awt.event
Interface ContainerListener

The listener interface for receiving container events. The class that is interested in processing a container event either implements this interface (and all the methods it contains) or extends the abstract ContainerAdapter class (overriding only the methods of interest). The listener object created from that class is then registered with a component using the component's addContainerListener method. When the container's contents change because a component has been added or removed, the relevant method in the listener object is invoked, and the ContainerEvent is passed to it.

AWTEventMulticaster

2008-05-05T18:25:00.000-07:00

java.awt
Class AWTEventMulticaster

java.lang.Object
 java.awt.AWTEventMulticaster

public class AWTEventMulticaster
extends Object
implements ComponentListener, ContainerListener, FocusListener, KeyListener, MouseListener, MouseMotionListener, WindowListener, WindowFocusListener, WindowStateListener, ActionListener, ItemListener, AdjustmentListener, TextListener, InputMethodListener, HierarchyListener, HierarchyBoundsListener, MouseWheelListener
extends Object
implements ComponentListener, ContainerListener, FocusListener, KeyListener, MouseListener, MouseMotionListener, WindowListener, WindowFocusListener, WindowStateListener, ActionListener, ItemListener, AdjustmentListener, TextListener, InputMethodListener, HierarchyListener, HierarchyBoundsListener, MouseWheelListener

A class which implements efficient and thread-safe multi-cast event dispatching for the AWT events defined in the java.awt.event package. This class will manage an immutable structure consisting of a chain of event listeners and will dispatch events to those listeners. Because the structure is immutable, it is safe to use this API to add/remove listeners during the process of an event dispatch operation. However, event listeners added during the process of an event dispatch operation will not be notified of the event currently being dispatched.

AlphaComposite

2008-05-05T18:23:00.000-07:00

java.awt
Class AlphaComposite

java.lang.Object
 java.awt.AlphaComposite

public final class AlphaComposite
extends Object
implements Composite
extends Object
implements Composite

The AlphaComposite class implements basic alpha compositing rules for combining source and destination colors to achieve blending and transparency effects with graphics and images. The specific rules implemented by this class are the basic set of 12 rules described in T. Porter and T. Duff, "Compositing Digital Images", SIGGRAPH 84, 253-259. The rest of this documentation assumes some familiarity with the definitions and concepts outlined in that paper.

This class extends the standard equations defined by Porter and Duff to include one additional factor. An instance of the AlphaComposite class can contain an alpha value that is used to modify the opacity or coverage of every source pixel before it is used in the blending equations.

It is important to note that the equations defined by the Porter and Duff paper are all defined to operate on color components that are premultiplied by their corresponding alpha components. Since the ColorModel and Raster classes allow the storage of pixel data in either premultiplied or non-premultiplied form, all input data must be normalized into premultiplied form before applying the equations and all results might need to be adjusted back to the form required by the destination before the pixel values are stored.

Also note that this class defines only the equations for combining color and alpha values in a purely mathematical sense. The accurate application of its equations depends on the way the data is retrieved from its sources and stored in its destinations. See Implementation Caveats for further information.

The following factors are used in the description of the blending equation in the Porter and Duff paper:

Factor Definition
A_s the alpha component of the source pixel
C_s a color component of the source pixel in premultiplied form
A_d the alpha component of the destination pixel
C_d a color component of the destination pixel in premultiplied form
F_s the fraction of the source pixel that contributes to the output
F_d the fraction of the destination pixel that contributes to the output
A_r the alpha component of the result
C_r a color component of the result in premultiplied form

Factor	Definition
A_s	the alpha component of the source pixel
C_s	a color component of the source pixel in premultiplied form
A_d	the alpha component of the destination pixel
C_d	a color component of the destination pixel in premultiplied form
F_s	the fraction of the source pixel that contributes to the output
F_d	the fraction of the destination pixel that contributes to the output
A_r	the alpha component of the result
C_r	a color component of the result in premultiplied form

Using these factors, Porter and Duff define 12 ways of choosing the blending factors F_s and F_d to produce each of 12 desirable visual effects. The equations for determining F_s and F_d are given in the descriptions of the 12 static fields that specify visual effects. For example, the description for SRC_OVER specifies that F_s = 1 and F_d = (1-A_s). Once a set of equations for determining the blending factors is known they can then be applied to each pixel to produce a result using the following set of equations:

F_s = f(A_d) F_d = f(A_s) A_r = A_s*F_s + A_d*F_d C_r = C_s*F_s + C_d*F_d

The following factors will be used to discuss our extensions to the blending equation in the Porter and Duff paper:

Factor Definition
C_sr one of the raw color components of the source pixel
C_dr one of the raw color components of the destination pixel
A_ac the "extra" alpha component from the AlphaComposite instance
A_sr the raw alpha component of the source pixel
A_dr the raw alpha component of the destination pixel
A_df the final alpha component stored in the destination
C_df the final raw color component stored in the destination

Factor	Definition
C_sr	one of the raw color components of the source pixel
C_dr	one of the raw color components of the destination pixel
A_ac	the "extra" alpha component from the AlphaComposite instance
A_sr	the raw alpha component of the source pixel
A_dr	the raw alpha component of the destination pixel
A_df	the final alpha component stored in the destination
C_df	the final raw color component stored in the destination

Preparing Inputs

The AlphaComposite class defines an additional alpha value that is applied to the source alpha. This value is applied as if an implicit SRC_IN rule were first applied to the source pixel against a pixel with the indicated alpha by multiplying both the raw source alpha and the raw source colors by the alpha in the AlphaComposite. This leads to the following equation for producing the alpha used in the Porter and Duff blending equation:

A_s = A_sr * A_ac All of the raw source color components need to be multiplied by the alpha in the AlphaComposite instance. Additionally, if the source was not in premultiplied form then the color components also need to be multiplied by the source alpha. Thus, the equation for producing the source color components for the Porter and Duff equation depends on whether the source pixels are premultiplied or not: C_s = C_sr * A_sr * A_ac (if source is not premultiplied) C_s = C_sr * A_ac (if source is premultiplied) No adjustment needs to be made to the destination alpha: A_d = A_dr

The destination color components need to be adjusted only if they are not in premultiplied form:

C_d = C_dr * A_d (if destination is not premultiplied) C_d = C_dr (if destination is premultiplied)

Applying the Blending Equation

The adjusted A_s, A_d, C_s, and C_d are used in the standard Porter and Duff equations to calculate the blending factors F_s and F_d and then the resulting premultiplied components A_r and C_r.

Preparing Results

The results only need to be adjusted if they are to be stored back into a destination buffer that holds data that is not premultiplied, using the following equations:

A_df = A_r C_df = C_r (if dest is premultiplied) C_df = C_r / A_r (if dest is not premultiplied) Note that since the division is undefined if the resulting alpha is zero, the division in that case is omitted to avoid the "divide by zero" and the color components are left as all zeros.

Performance Considerations

For performance reasons, it is preferrable that Raster objects passed to the compose method of a CompositeContext object created by the AlphaComposite class have premultiplied data. If either the source Raster or the destination Raster is not premultiplied, however, appropriate conversions are performed before and after the compositing operation.

Implementation Caveats

Many sources, such as some of the opaque image types listed in the BufferedImage class, do not store alpha values for their pixels. Such sources supply an alpha of 1.0 for all of their pixels.
Many destinations also have no place to store the alpha values that result from the blending calculations performed by this class. Such destinations thus implicitly discard the resulting alpha values that this class produces. It is recommended that such destinations should treat their stored color values as non-premultiplied and divide the resulting color values by the resulting alpha value before storing the color values and discarding the alpha value.
The accuracy of the results depends on the manner in which pixels are stored in the destination. An image format that provides at least 8 bits of storage per color and alpha component is at least adequate for use as a destination for a sequence of a few to a dozen compositing operations. An image format with fewer than 8 bits of storage per component is of limited use for just one or two compositing operations before the rounding errors dominate the results. An image format that does not separately store color components is not a good candidate for any type of translucent blending. For example, BufferedImage.TYPE_BYTE_INDEXED should not be used as a destination for a blending operation because every operation can introduce large errors, due to the need to choose a pixel from a limited palette to match the results of the blending equations.
Nearly all formats store pixels as discrete integers rather than the floating point values used in the reference equations above. The implementation can either scale the integer pixel values into floating point values in the range 0.0 to 1.0 or use slightly modified versions of the equations that operate entirely in the integer domain and yet produce analogous results to the reference equations.
Typically the integer values are related to the floating point values in such a way that the integer 0 is equated to the floating point value 0.0 and the integer 2^n-1 (where n is the number of bits in the representation) is equated to 1.0. For 8-bit representations, this means that 0x00 represents 0.0 and 0xff represents 1.0.
The internal implementation can approximate some of the equations and it can also eliminate some steps to avoid unnecessary operations. For example, consider a discrete integer image with non-premultiplied alpha values that uses 8 bits per component for storage. The stored values for a nearly transparent darkened red might be:
```
    (A, R, G, B) = (0x01, 0xb0, 0x00, 0x00)
```
If integer math were being used and this value were being composited in SRC mode with no extra alpha, then the math would indicate that the results were (in integer format):
```
    (A, R, G, B) = (0x01, 0x01, 0x00, 0x00)
```
Note that the intermediate values, which are always in premultiplied form, would only allow the integer red component to be either 0x00 or 0x01. When we try to store this result back into a destination that is not premultiplied, dividing out the alpha will give us very few choices for the non-premultiplied red value. In this case an implementation that performs the math in integer space without shortcuts is likely to end up with the final pixel values of:
```
    (A, R, G, B) = (0x01, 0xff, 0x00, 0x00)
```
(Note that 0x01 divided by 0x01 gives you 1.0, which is equivalent to the value 0xff in an 8-bit storage format.)
Alternately, an implementation that uses floating point math might produce more accurate results and end up returning to the original pixel value with little, if any, roundoff error. Or, an implementation using integer math might decide that since the equations boil down to a virtual NOP on the color values if performed in a floating point space, it can transfer the pixel untouched to the destination and avoid all the math entirely.
These implementations all attempt to honor the same equations, but use different tradeoffs of integer and floating point math and reduced or full equations. To account for such differences, it is probably best to expect only that the premultiplied form of the results to match between implementations and image formats. In this case both answers, expressed in premultiplied form would equate to:
```
    (A, R, G, B) = (0x01, 0x01, 0x00, 0x00)
```
and thus they would all match.
Because of the technique of simplifying the equations for calculation efficiency, some implementations might perform differently when encountering result alpha values of 0.0 on a non-premultiplied destination. Note that the simplification of removing the divide by alpha in the case of the SRC rule is technically not valid if the denominator (alpha) is 0. But, since the results should only be expected to be accurate when viewed in premultiplied form, a resulting alpha of 0 essentially renders the resulting color components irrelevant and so exact behavior in this case should not be expected.

PopupMenu.AccessibleAWTPopupMenu

2008-05-05T18:22:00.001-07:00

java.awt
Class PopupMenu.AccessibleAWTPopupMenu

java.lang.Object
 javax.accessibility.AccessibleContext
     java.awt.MenuComponent.AccessibleAWTMenuComponent
         java.awt.MenuItem.AccessibleAWTMenuItem
             java.awt.Menu.AccessibleAWTMenu
                 java.awt.PopupMenu.AccessibleAWTPopupMenu

protected class PopupMenu.AccessibleAWTPopupMenu
extends Menu.AccessibleAWTMenu
extends Menu.AccessibleAWTMenu

Inner class of PopupMenu used to provide default support for accessibility. This class is not meant to be used directly by application developers, but is instead meant only to be subclassed by menu component developers.

The class used to obtain the accessible role for this object.

Menu.AccessibleAWTMenu

2008-05-05T18:21:00.001-07:00

java.awt
Class Menu.AccessibleAWTMenu

java.lang.Object
 javax.accessibility.AccessibleContext
     java.awt.MenuComponent.AccessibleAWTMenuComponent
         java.awt.MenuItem.AccessibleAWTMenuItem
             java.awt.Menu.AccessibleAWTMenu

protected class Menu.AccessibleAWTMenu
extends MenuItem.AccessibleAWTMenuItem
extends MenuItem.AccessibleAWTMenuItem

Inner class of Menu used to provide default support for accessibility. This class is not meant to be used directly by application developers, but is instead meant only to be subclassed by menu component developers.

This class implements accessibility support for the Menu class. It provides an implementation of the Java Accessibility API appropriate to menu user-interface elements.

CheckboxMenuItem.AccessibleAWTCheckboxMenuItem

2008-05-05T18:18:00.000-07:00

java.awt
Class CheckboxMenuItem.AccessibleAWTCheckboxMenuItem

java.lang.Object
 javax.accessibility.AccessibleContext
     java.awt.MenuComponent.AccessibleAWTMenuComponent
         java.awt.MenuItem.AccessibleAWTMenuItem
             java.awt.CheckboxMenuItem.AccessibleAWTCheckboxMenuItem

protected class CheckboxMenuItem.AccessibleAWTCheckboxMenuItem
extends MenuItem.AccessibleAWTMenuItem
implements AccessibleAction, AccessibleValue
extends MenuItem.AccessibleAWTMenuItem
implements AccessibleAction, AccessibleValue

Inner class of CheckboxMenuItem used to provide default support for accessibility. This class is not meant to be used directly by application developers, but is instead meant only to be subclassed by menu component developers.

This class implements accessibility support for the CheckboxMenuItem class. It provides an implementation of the Java Accessibility API appropriate to checkbox menu item user-interface elements.

MenuItem.AccessibleAWTMenuItem

2008-05-05T18:17:00.000-07:00

java.awt
Class MenuItem.AccessibleAWTMenuItem

java.lang.Object
 javax.accessibility.AccessibleContext
     java.awt.MenuComponent.AccessibleAWTMenuComponent
         java.awt.MenuItem.AccessibleAWTMenuItem

protected class MenuItem.AccessibleAWTMenuItem
extends MenuComponent.AccessibleAWTMenuComponent
implements AccessibleAction, AccessibleValue
extends MenuComponent.AccessibleAWTMenuComponent
implements AccessibleAction, AccessibleValue

Inner class of MenuItem used to provide default support for accessibility. This class is not meant to be used directly by application developers, but is instead meant only to be subclassed by menu component developers.

This class implements accessibility support for the MenuItem class. It provides an implementation of the Java Accessibility API appropriate to menu item user-interface elements.

MenuBar.AccessibleAWTMenuBar

2008-04-09T21:08:00.000-07:00

java.awt
Class MenuBar.AccessibleAWTMenuBar

java.lang.Object
 javax.accessibility.AccessibleContext
     java.awt.MenuComponent.AccessibleAWTMenuComponent
         java.awt.MenuBar.AccessibleAWTMenuBar

protected class MenuBar.AccessibleAWTMenuBar
extends MenuComponent.AccessibleAWTMenuComponent
extends MenuComponent.AccessibleAWTMenuComponent

Inner class of MenuBar used to provide default support for accessibility. This class is not meant to be used directly by application developers, but is instead meant only to be subclassed by menu component developers.

This class implements accessibility support for the MenuBar class. It provides an implementation of the Java Accessibility API appropriate to menu bar user-interface elements.

MenuComponent.AccessibleAWTMenuComponent

2008-04-09T21:06:00.000-07:00

java.awt
Class MenuComponent.AccessibleAWTMenuComponent

java.lang.Object
 javax.accessibility.AccessibleContext
     java.awt.MenuComponent.AccessibleAWTMenuComponent

protected abstract class MenuComponent.AccessibleAWTMenuComponent
extends AccessibleContext
implements Serializable, AccessibleComponent, AccessibleSelection
extends AccessibleContext
implements Serializable, AccessibleComponent, AccessibleSelection

Inner class of MenuComponent used to provide default support for accessibility. This class is not meant to be used directly by application developers, but is instead meant only to be subclassed by menu component developers.

The class used to obtain the accessible role for this object.

TextField.AccessibleAWTTextField

2008-03-22T20:15:00.002-07:00

java.awt
Class TextField.AccessibleAWTTextField

java.lang.Object
 javax.accessibility.AccessibleContext
     java.awt.Component.AccessibleAWTComponent
         java.awt.TextComponent.AccessibleAWTTextComponent
             java.awt.TextField.AccessibleAWTTextField

protected class TextField.AccessibleAWTTextField
extends TextComponent.AccessibleAWTTextComponent
extends TextComponent.AccessibleAWTTextComponent

This class implements accessibility support for the TextField class. It provides an implementation of the Java Accessibility API appropriate to text field user-interface elements.

TextArea.AccessibleAWTTextArea

2008-03-22T20:15:00.001-07:00

java.awt
Class TextArea.AccessibleAWTTextArea

java.lang.Object
 javax.accessibility.AccessibleContext
     java.awt.Component.AccessibleAWTComponent
         java.awt.TextComponent.AccessibleAWTTextComponent
             java.awt.TextArea.AccessibleAWTTextArea

protected class TextArea.AccessibleAWTTextArea
extends TextComponent.AccessibleAWTTextComponent
extends TextComponent.AccessibleAWTTextComponent

This class implements accessibility support for the TextArea class. It provides an implementation of the Java Accessibility API appropriate to text area user-interface elements.

Java Tutorial & Books Download

Component

java.awtClass Component

SystemColor

java.awtClass SystemColor

Class Color

java.awtClass Color