[3429] in java-interest

home help back first fref pref prev next nref lref last post

Re: TextArea and handleEvent

daemon@ATHENA.MIT.EDU (Gary Aitken)
Sat Nov 11 23:14:00 1995

Date: Sat, 11 Nov 1995 19:28:17 -0700
From: garya@village.org (Gary Aitken)
To: Java Mailing Lists <java@vv.val.net>, java-interest@java.sun.com

> i'm trying to intercept the <enter> key from a textarea object. i have
>  tried the following:
>
>class Editor extends TextArea
>{
>public boolean handleEvent( Event evt )
>{
> ... handleEvent code here ....
>}
>}
>
> the problem is that handleEvent never seems to get called. what am i
> doing wrong? is there a better way of doing this?

I think you have hit a bug (or two).
I may be way off base here, but I'll take a shot at it...

Let's assume you instantiate your Editor as object ed in a Frame called main.
This gives you an object tree which looks like:

	main (a Frame)
	  ed (an Editor)

Events are delivered as follows, as nearly as I can figure out:

	The native environment delivers the event to the Java library
	(I can't track down how since there are no references
	to deliverEvent outside of Component.java and Container.java
	in the source distributed with Beta).  Eventually,
		xxx.deliverEvent
	should get called to process the event, where xxx is the object
	with the input focus (ed in this case)

The event delivery mechanism has three components:

	deliverEvent
		Routes the event to the appropriate interior object.
		This should be the innermost object for the event coordinates
		where the event occurred.  For pointer events, it should be the
		object under the pointer (in most cases).  For Keyboard events,
		it should be the object with the keyboard focus.
	postEvent
		Routes the event to the native toolkit object for processing,
		or to the java object for processing.  If the java object 
		decides not to handle the event, propagates it up to the 
		parent object. The native toolkit part of this is bug#2 below.
	handleEvent
		Processes the event (possibly)

The overrides of these three functions are as follows:

	Component		deliverEvent	postEvent	handleEvent
	  Container		deliverEvent	--		--
	    Window		--			--		--
	      Frame		--			--		--

	Component		deliverEvent	postEvent	handleEvent
	  TextComponent	--			--		--
	    TextArea	--			--		--
	      Editor	--			--		handleEvent

What *should* happen (I think) is the following,
assuming you have clicked on ed to get the input focus there:

	The event gets delivered to ed's Component.deliverEvent

	bug #1:
		This does not happen on Win95 (I don't think -- justification
		for this appears below after bug #2 where we override 
		postEvent); 
		I don't know what happens on a unix machine running Motif; 
		I don't have one handy to test with.

	ed's Component.deliverEvent simply calls postEvent which
	is ed's Component.postEvent.
	
	Component.postEvent checks to see if a peer object exists
	(a peer object is a native window system object)
	If one does, it delivers the event to it.
	If a peer did not exist, or the peer did not process the event,
	postEvent calls handleEvent.

	bug #2:
		The call to peer.handleEvent prevents your override of 
		handleEvent from getting called, as the peer object will 
		process the event (the peer is a text object which does 
		something with most key events).  
		The check for the peer and the call to peer.handleEvent
		should appear at the top of Component.handleEvent instead of
		in Component.postEvent

	In order to get around the above bug #2, you *should* be able to
	override postEvent.  However, doing so does not correct the problem,
	indicating that bug #1 exists.  If you are on a unix system you
	might try this, just in case it solves the problem there.  I don't
	think it will, however.

Unfortunately, this does not solve your problem, but it does, I hope, 
provide some additional information which may help find it.

If, instead of deriving from a text object, you derive from something
like a Panel, which has a peer object which does not consume key events,
you will see that your override of handleEvent works,
an indication that there is a bug in the event delivery mechanism,
or at least that it does not have uniform behavior.

Gary Aitken		garya@village.org
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post