Home >> All >> java >> awt >> [ event Javadoc ]

• java.awt.event: Javadoc index of package java.awt.event.


Package Samples:

• java.awt.event

Classes:

• KeyEvent: This event is generated when a key is pressed or released. There are two categories of key events: "Key typed" events are higher-level, and have already compensated for modifiers and keyboard layout to generate a single Unicode character. It may take several key press events to generate one key typed. The getKeyCode method will return VK_UNDEFINED , and getKeyChar will return a valid Unicode character or CHAR_UNDEFINED . "Key pressed" and "key released" events are lower-level, and are platform and keyboard dependent. They correspond to the actaul motion on a keyboard, and return a virtual key code ...
• MouseEvent: This event is generated for a mouse event. There are three main categories of mouse events: Regular events include pressing, releasing, and clicking buttons, as well as moving over the boundary of the unobscured portion of a component. Motion events include movement and dragging. Wheel events are covered separately by the subclass MouseWheelEvent. A mouse event is tied to the unobstructed visible component that the mouse cursor was over at the time of the action. The button that was most recently pressed is the only one that shows up in getModifiers , and is returned by getButton , while all buttons ...
• MouseWheelEvent: This event is generated for a mouse wheel rotation. The wheel (the middle mouse button on most modern mice) can be rotated towards or away from the user, and is often used for scrolling. Because of the special use for scrolling components, MouseWheelEvents often affect a different component than the one located at the point of the event. If the component under the mouse cursor does not accept wheel events, the event is passed to the first ancestor container which does. This is often a ScrollPane, which knows how to scroll. If an AWT component is built from a native widget that knows how to use ...
• HierarchyEvent: This class represents an event generated for an ancestor component which may affect this component. These events normally do not need to be handled by the application, since the AWT system automatically takes care of them. There are two types of hierarchy events. The first type is handled by HierarchyListener, and includes addition or removal of an ancestor, or an ancestor changing its on-screen status (visible and/or displayble). The second type is handled by HierarchyBoundsListener, and includes resizing or moving of an ancestor.
• WindowEvent: This event is generated when there is a change in a window. This includes creation, closing, iconification, activation, and focus changes. There are three listeners, for three types of events: WindowListeners deal with the lifecycle of a window, WindowStateListeners deal with window state like maximization, and WindowFocusListeners deal with focus switching to or from a window.
• MouseListener: This interface is for classes that wish to receive mouse events other than simple motion events. This includes clicks (but not mouse wheel events), and crossing component boundaries without change in button status. To track moves and drags, use MouseMotionListener, and to track wheel events, use MouseWheelListener. To watch a subset of these events, use a MouseAdapter.
• InvocationEvent: This event executes Runnable.run() > Runnable.run() 55 of a target object when it is dispatched. This class is used by calls to invokeLater and invokeAndWait , so client code can use this fact to avoid writing special-casing AWTEventListener objects.
• WindowAdapter: This class implements WindowListener , WindowStateListener , and WindowFocusListener , and implements all methods with empty bodies. This allows a listener interested in listening to only a subset of any WindowEvent actions to extend this class and override only the desired methods.
• ComponentEvent: This class is for events generated when a component is moved, resized, hidden, or shown. These events normally do not need to be handled by the application, since the AWT system automatically takes care of them. This is also the superclass for other events on components, but ComponentListeners ignore such subclasses.
• HierarchyBoundsAdapter: This class implements HierarchyBoundsListener and implements all methods with empty bodies. This allows a listener interested in implementing only a subset of the HierarchyBoundsListener interface to extend this class and override only the desired methods.
• MouseMotionAdapter: This class implements MouseMotionListener and implements all methods with empty bodies. This allows a listener interested in implementing only a subset of the MouseMotionListener interface to extend this class and override only the desired methods.
• MouseMotionListener: This interface is for classes that wish to be notified of mouse movements. This includes moves and drags, but not crossing component boundaries. To track other mouse events, use MouseListener or MouseWheelListener. To watch a subset of these events, use a MouseMotionAdapter.
• ComponentAdapter: This class implements ComponentListener and implements all methods with empty bodies. This allows a listener interested in implementing only a subset of the ComponentListener interface to extend this class and override only the desired methods.
• ContainerAdapter: This class implements ContainerListener and implements all methods with empty bodies. This allows a listener interested in implementing only a subset of the ContainerListener interface to extend this class and override only the desired methods.
• FocusAdapter: This class implements FocusListener and implements all methods with empty bodies. This allows a listener interested in implementing only a subset of the FocusListener interface to extend this class and override only the desired methods.
• MouseAdapter: This class implements MouseListener and implements all methods with empty bodies. This allows a listener interested in implementing only a subset of the MouseListener interface to extend this class and override only the desired methods.
• KeyAdapter: This class implements KeyListener and implements all methods with empty bodies. This allows a listener interested in implementing only a subset of the KeyListener interface to extend this class and override only the desired methods.
• FocusEvent: This class represents an event generated when a focus change occurs for a component. There are both temporary changes, such as when focus is stolen during a sroll then returned, and permanent changes, such as when the user TABs through focusable components.
• ComponentListener: This interface is for classes that receive all events from a component. Normally it is not necessary to process these events since the AWT handles them internally, taking all appropriate actions. To watch a subset of these events, use a ComponentAdapter.
• HierarchyBoundsListener: This listens for changes in an ancestors size or location. Normally it is not necessary to process these events since the AWT handles them internally, taking all appropriate actions. To watch a subset of these events, use a HierarchyBoundsAdapter.
• ContainerListener: This interface is for classes that wish to listen for all events from container objects. This is normally not necessary since the AWT system listens for and processes these events. To watch a subset of these events, use a ContainerAdapter.
• ItemEvent: This event is generated when a selection item changes state. This is an abstraction that distills a large number of individual mouse or keyboard events into a simpler "item selected" and "item deselected" events.
• PaintEvent: This event is generated when an area of the screen needs to be painted. This event is not meant for users, but exists to allow proper serialization behavior in the EventQueue with user-accessible events.
• InputEvent: This is the common superclass for all component input classes. These are passed to listeners before the component, so that listeners can consume the event before it does its default behavior.
• HierarchyListener: This listens for changes in the hierarchy tree of components. Normally it is not necessary to process these events since the AWT handles them internally, taking all appropriate actions.

Home | Contact Us | Privacy Policy | Terms of Service