UNIT VI EVENT HANDLING

UNIT VI EVENT HANDLING

The Delegation Event Model The modern approach to handling events is based on the delegation event model, which defines standard and consistent mechanisms to generate and process events. Its concept is quite simple: a source generates an event and sends it to one or more listeners. In this scheme, the listener simply waits until it receives an event. Once received, the listener processes the event and then returns. The advantage of this design is that the application logic that processes events is cleanly separated from the user interface logic that generates those events. In the delegation event model, listeners must register with a source in order to receive an event notification. This provides an important benefit: notifications are sent only to listeners that want to receive them. This is a more efficient way to handle events than the design used by the old Java 1. approach.

Events
In the delegation model, an event is an ob!ect that describes a state change in a source. It can be generated as a consequence of a person interacting with the elements in a graphical user interface. "ome of the activities that cause events to be generated are pressing a button, entering a character via the #eyboard, selecting an item in a list, and clic#ing the mouse. $vents may also occur that are not directly caused by interactions with a user interface. %or e&ample, an event may be generated when a timer e&pires, a counter e&ceeds a value, a software or hardware failure occurs, or an operation is completed.

Event Sources
' source is an ob!ect that generates an event. This occurs when the internal state of that ob!ect changes in some way. "ources may generate more than one type of event. ' source must register listeners in order for the listeners to receive notifications about a specific type of event. $ach type of event has its own registration method.(ere is the general form: public void add Type)istener*Type)istener el+ (ere, Type is the name, of the event and el is a reference to the event listener. %or e&ample, the method that registers a #eyboard event listener is called addKe Listener!". The method that registers a mouse motion listener is called addMouseMotionListener!".

Event Listeners#
' listener is an ob!ect that is notified when an event occurs. It has two ma!or requirements. %irst, it must have been registered with one or more sources to receive notifications about specific types of events. "econd, it must implement methods to receive and process these notifications. The methods that receive and process events are defined in a set of interfaces found in $ava%a&t%event. %or e&ample, the MouseMotionListener interface defines two methods to receive notifications when the mouse is dragged or moved. 'ny ob!ect may receive and process one or both of these events if it provides an implementation of this interface.

Event Listener Inter'aces

6.1 Prepared by PHANI KISHORE ROMPICHRLA

UNIT VI EVENT HANDLING

The delegation event model has two parts: sources and listeners. )isteners are created by implementing one or more of the interfaces defined by the $ava%a&t%event pac#age. -hen an event occurs, the event source invo#es the appropriate method defined by the listener and provides an event ob!ect as its argument Ada(ter )lasses Java provides a special feature, called an adapter class, that can simplify the creation of event handlers in certain situations. 'n adapter class provides an empty implementation of all methods in an event listener interface. 'dapter classes are useful when you want to receive and process only some of the events that are handled by a particular event listener interface. .ou can define a new class to act as an event listener by e&tending one of the adapter classes and implementing only those events in which you are interested. %or e&ample, the MouseMotionAda(ter class has two methods, *ouseDragged! " and *ouseMoved! ". The signatures of these empty methods are e&actly as defined in the MouseMotionListener interface. If you were interested in only mouse drag events, then you could simply e&tend MouseMotionAda(ter and implement *ouseDragged! ". The empty implementation of *ouseMoved! " would handle the mouse motion events for you. Anon *ous Inner )lasses 'n anonymous inner class is one that is not assigned a name. This section illustrates how an anonymous inner class can facilitate the writing of event handlers. /onsider the applet shown in the following listing. 's before, its goal is to display the string 01ouse 2ressed3 in the status bar of the applet viewer or browser when the mouse is pressed. La out Manager a layout manager automatically arranges your controls within a window by using some type of algorithm.$ach )ontainer ob!ect has a layout manager associated with it. ' layout manager is an instance of any class that implements the La outManager interface. The layout manager is set by the setLa out! " method. If no call to setLa out! " is made, then the default layout manager is used. -henever a container is resi4ed *or si4ed for the first time+, the layout manager is used to position each of the components within it. The setLa out! " method has the following general form: void set)ayout*)ayout1anager layoutObj+ (ere, layoutObj is a reference to the desired layout manager. If you wish to disable the layout manager and position components manually, pass null for layoutObj. If you do this, you will need to determine the shape and position of each component manually,using the set+ounds! " method defined by )o*(onent. 5ormally, you will want to use a layout manager.$ach layout manager #eeps trac# of a list of components that are stored by their names. The layout manager is notified each time you add a component to a container. -henever the container needs to be resi4ed, the layout manager is consulted via its *ini*u*La outSi,e! " and (re'erredLa outSi,e! " methods. $ach component that is being managed by a layout manager contains the get-re'erredSi,e! " and getMini*u*Si,e! " methods.
.L/0LA1/UT#

.lo&La out is the default layout manager. This is the layout manager that the preceding e&amples have used. .lo&La out implements a simple layout style, which is similar to how words flow in a te&t editor./omponents are laid out from the upper6left corner, left to right and top to bottom. -hen no more components fit on a line, the ne&t one appears on the ne&t line. ' small space is left between each component, above and below, as well as left and right. (ere are the constructors for .lo&La out: 6.2 %low)ayout* + Prepared by PHANI KISHORE ROMPICHRLA

UNIT VI EVENT HANDLING

%low)ayout*int how+ %low)ayout*int how, int horz, int vert+

+/2DE2 LA1/UT#

The +orderLa out class implements a common layout style for top6level windows. It has four narrow,fi&ed6width components at the edges and one large area in the center. The four sides are referred to as north, south, east, and west. The middle area is called the center. (ere are the constructors defined by +orderLa out: 7order)ayout* + 7order)ayout*int horz, int vert+ The first form creates a default border layout. The second allows you to specify the hori4ontal and vertical space left between components in horz and vert, respectively. +orderLa out defines the following constants that specify the regions: 7order)ayout./$5T$8 7order)ayout."O9T( 7order)ayout.$'"T 7order)ayout.-$"T 7order)ayout.5O8T(
G2ID LA1/UT#

GridLa out lays out components in a two6dimensional grid. -hen you instantiate a GridLa out, you define the number of rows and columns. The constructors supported by GridLa out are shown here: :rid)ayout* + :rid)ayout*int numRows, int numColumns + :rid)ayout*int numRows, int numColumns, int horz, int vert+ The first form creates a single6column grid layout. The second form creates a grid layout with the specified number of rows and columns. The third form allows youto specify the hori4ontal and vertical space left between components in horz and vert, respectively. $ither numRows or numColumns can be 4ero. "pecifying numRows as 4ero allows for unlimited6length columns. "pecifying numColumns as 4ero allows for unlimited6length rows $g: see the e&ample which I was given in running notes
)A2D LA1/UT#

The )ardLa out class is unique among the other layout managers in that it stores several different layouts. $ach layout can be thought of as being on a separate inde& card in a dec# that can be shuffled so that any card is on top at a given time. This can be useful for user interfaces with optional components that can be dynamically enabled and disabled upon user input. .ou can prepare the other layouts and have them hidden, ready to be activated when needed. )ardLa out provides these two constructors: /ard)ayout* + /ard)ayout*int horz, int vert+ The first form creates a default card layout. The second form allows you to specify the hori4ontal 6.3 Prepared by PHANI KISHORE ROMPICHRLA

UNIT VI EVENT HANDLING

andvertical space left between components in horz and vert, respectively. 9se of a card layout requires a bit more wor# than the other layouts. The cards are typically held in an ob!ect of type -anel. This panel must have )ardLa out selected as its layout manager. The cards that form the dec# are also typically ob!ects of type -anel. Thus, you must create a panel that contains the dec# and a panel for each card in the dec#. 5e&t, you add to the appropriate panel the components that form each card. .ou then add these panels to the panel for which )ardLa out is the layout manager. %inally, you add this panel to the main applet panel.
G2ID+AG LA1/UT#

9sing :rid7ag)ayout class you can specify the relative placement of components by specifying this positions within cells inside a grid. The #ey to :rid7ag is that each component can be a different si4e and each row in the grid can have a different number of columns this is why the layout is called a grid7ag It is a collection of small grids !oined together. The location and si4e of each component in a grid7ag are determined by a set of constraints lin#ed to it. The constraints are contained in an ob!ect of type :rid7ag/onstraints. /onstraints include the height and width of a cell the placement of acomponent and

its alignement.
-ANEL#

The -anel class is a concrete subclass of )ontainer. It doesn;t add any new methods< it simply implements .' -anel may be thought of as a recursively nestable, concrete screen component. -anel is the superclass for A((let. -hen screen output is directed to an applet, it is drawn on the surface of a -anel ob!ect. In essence, a -anel is a window that does not contain a title bar, menu bar, or border. This is why you don;t see these items when an applet is run inside a browser. -hen you run an applet using an applet viewer, the applet viewer provides the title and border. Other components can be added to a -anel ob!ect by its add! " method *inherited from )ontainer+. Once these components have been added, you can position and resi4e them manually using the setLocation! ", setSi,e! ", or set+ounds! " methods defined by component.
)/NTAINE2#

The )ontainer class is a subclass of )o*(onent. It has additional methods that allow other )o*(onent ob!ects to be nested within it. Other )ontainer ob!ects can be stored inside of a )ontainer *since they are themselves instances of )o*(onent+. This ma#es for a multileveled c ontainment system. ' container is responsible for laying out *that is, positioning+ any components that it contains.
0IND/0#

The 0indo& class creates a top6level window. ' top-level window is not contained within any other ob!ect< it sits directly on the des#top. :enerally, you won;t create 0indo& ob!ects directly. Instead, you will use a subclass of 0indo& called .ra*e.
.2AME#

.ra*e encapsulates what is commonly thought of as a 0window.3 It is a subclass of 0indo& and has a title bar, menu bar, borders, and resi4ing corners. If you create a .ra*e ob!ect from within an applet, it will contain a warning message, such as 0Java 'pplet -indow,3 to the user that an applet window has been created. This message warns users that the window they see was started by an applet and not by software running on their computer. *'n applet that could masquerade as a host6based application could be used to obtain passwords and other sensitive information without the user;s #nowledge.+ -hen a .ra*e window is created by a program rather than an applet, a normal window is created. 6.4 Prepared by PHANI KISHORE ROMPICHRLA

UNIT VI EVENT HANDLING

)reating a .ra*e 0indo& in an A((let -hile it is possible to simply create a window by creating an instance of .ra*e, you will seldom do so, because you will not be able to do much with it. %or e&ample, you will not be able to receive or process events that occur within it or easily output information to it. 1ost of the time, you will create a subclass of .ra*e. =oing so lets you override .ra*e;s methods and event handling. /reating a new frame window from within an applet is actually quite easy. %irst, create a subclass of .ra*e. 5e&t, override any of the standard window methods, such as init! ", start! ", sto(! ", and (aint! ". %inally, implement the &indo&)losing! " method of the 0indo&Listener interface, calling setVisi3le!'alse" when the window is closed

6.5

Prepared by PHANI KISHORE ROMPICHRLA