[5262] in java-interest
Event and Paint handling in AWT
daemon@ATHENA.MIT.EDU (Avner Aviad)
Sun Feb 4 15:45:39 1996
From: Avner Aviad <aaviad@netvision.net.il>
To: "'Java Interest'" <java-interest@java.sun.com>
Cc: "'Randy Nielsen'" <rnielsen@webra.com>
Date: Sun, 4 Feb 1996 21:24:14 +-200
The following is a quote from http://java.sun.com/JDK-1.0/faq.html:
-----------
Is there a new event model in the 1.0 JDK?=20
Yes. In beta and earlier versions of the JDK, programs using the =
AWT couldn't intercept events that
were sent to native widgets. Now they can. In theory, an AWT =
program can subclass a component,
say a TextField, override its handleEvent() method, and can then:=20
1.Pass the event along unmodified, by returning false.=20
2.Pass the event along with modifications by modifying the event =
and then returning false.=20
3.Consume the event without passing it on by returning true.=20
If a component's handleEvent() method returns false, the event =
keeps traveling up the containment
hierarchy. If none of the component's parents return true from =
their handleEvent() methods, the event
is then sent to the peer which will then consume the event.=20
For 1.0, however, the only events that an AWT program can filter =
are keyboard events. Future
versions of the JDK will allow the AWT to filter all events.=20
Note also that if an applet's TextFields don't seem to be getting =
any keyboard input, it's because the
applet is incorrectly written to return "true" from it's =
handleEvent() method. This causes the event not
to be sent to the actual TextField.=20
------------
Note that this solves the mystery about Events that are missing from =
native applet components. I think that this issue should be on top of =
the list to fix in the next round because it makes AWT really non =
extendible. Note that even the loss of focus is not passed to a =
TextField which is really a minimum even if sun chose to implement only =
Key Actions.
Few important issues here:
1. Can we expect this issue to be resolved soon?
2. Is there a workaround at least to be able to detect the loss of focus =
(not by keyboard monitoring because the loss of focus can happen by =
mouse action) ?
3. Do the sun people realize that the same problematic functionality =
hold also for painting of AWT components? As things stand, we have no =
way to override painting of AWT components other then Canvas and =
Containers. The correct functinality should be
to pass the paint() and update() calls to the Java derived component and =
let it invoke the default painting of the native AWT object. I am =
worried that at this point, since the API is frozen (for a while) and =
these methods are 'void' this is not in sun's plan.
does anyone have any suggestions? Comments? How about Sun?
--------------------------------------------------
Avner Aviad - Webra Software Inc. =20
EMail: aaviad@netvision.net.il
Web: http://www.netvision.net.il/php/aaviad
--------------------------------------------------=20
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
