This week we're going to delve a little further into Events under Java.

Last week our introductory coverage of events was limited, more or less, to the most basic events and event-related methods in Java. This time we're going to look at a bit more of the bigger picture and answer a few questions about what was only hinted at last week.

Let's start with the event-specific methods. According to the documentation, there are about eight: mouseEnter, mouseExit, mouseMove, mouseUp, mouseDown, mouseDrag, keyDown, and action.

The simple side of these methods is that, yes, you can redefine them yourself in your own applets, and yes, when these events occur within the purview of your applet, whatever you've written into them will execute (with action being the exception, but we'll get to that in a minute). The catch? Actually, there is none; just a few cautionary notes.

One should definitely be aware of the underlying fashion by which events are woven into the language and the way in which these methods are used only as shortcuts. To illustrate, let's look a little closer at mouseDown as we've used it in our sample program of weeks past:

 public boolean mouseDown (java.awt.Event evt,int x,int y) {

      buffer = new StringBuffer("Thank You!");

      repaint();

      return(false);

   }

There are mysterious things defined in the parentheses after the method name. Perhaps somewhat obvious, the values that the Applet viewer will place into x and y (which are defined as integer variables, to the uninitiated) when this method runs are going to be the x and y coordinates, in pixels, that the mouse pointer was over when the user clicked. So what about the mysterious java.awt.Event evt?

Deeper at the heart of how Java must relate to events is a class, encompassing methods, information, and a few simple routines, not surprisingly called java.awt.Event. When we refer to it, and in fact instantiate it (creating an actual object based on the definition, or class) within our new mouseDown method, we're preparing to receive a body of generic event information. The details are all in the API, as well as the tutorial.

Summing up, this provides information about the type of event that occurred, the x and y coordinates and/or the key pressed (in the case of a keyboard event), time stamp (exact time of the event, as far as the window manager on the client system knows), state of the modifier keys (SHIFT, ALT, CTRL,etc.) at the time of the event, and so on. In our specific case, most of this information is redundant. We know what kind of event we're having; this is an event-associated method after all. Additionally, we've already got x and y coordinates separately passed as parameters to our method.

Regardless of the fact that we don't use any of this information in our routine, that's more or less irrelevant. You can, and hopefully you will, find uses for it. An important thing to keep in mind while doing so, however, is that your event-handling methods completely "captivate" your applet while they are running. What we mean by this is that nothing else is going on until the event has been completely "handled." As a result, most people use event handlers to spawn thr eads if they intend complex and time-consuming actions to follow from user input. We'll be covering the mysterious thread in detail in a few weeks.

Back to our main point, the mouseDown method really is a shortcut. This time it was an expedient one; we didn't have to distinguish what the user was clicking on, we didn't care about when the user clicked, we only cared that the user did or did not click on it.

Undoubtedly the need will eventually arise for a more complex way of realizing what the user is up to. Higher up in the event-handling hierarchy are two significant methods, one of which we've already mentioned: action and handleEvent. Starting with action() is recommended; dealing with handleEvent may get you deeper into the fray than you expect.

Next week, we'll experiment with action() and by way of this find ourselves far more deeply immersed in the way Java organizes the elements of its user interface. Here's a hint at how that's done well with objects.

Past installments of Java Jolt