Java

JavaTM 2 SDK, v1. 4 에서의 AWT 의 확장 기능

 문서의 목차
1.4. 2 버그의 수정
1.4. 1 버그의 수정
새로운 포커스 하부조직
추천 되지 않는 Focus 메소드
타임 스탬프를 필요로 하는 ActionEvent ( 및 그 외의 이벤트)
헷드레스사포트
멀티스크린의 지원에 필요한 윈도우의 중앙 배치
새로운 전화면 배타 모드 API
Windows NT 에서의 비디오 드라이버의 Sync Out of Range 에러 비장식 프레임
마우스 휠의 지원
Frame의 프로그래밍 줌
사이즈 변경시의 동적인 레이아웃
컴퍼넌트 청취자 리스트에의 액세스
드래그＆드롭의 변경점
64 비트 대응의 Solaris
일관성이 없는 DLL 경고
DrawingSurface API 의 삭제
새로운 InputEvent 키 수식자
Choice 메뉴의 드롭 다운 동작의 변경점
선택 컴퍼넌트는 레이아웃 매니저 제한으로 적합
1.4. 2 버그의 수정

4648702 : Microsoft Windows 2000 및 Windows XP 상에서는,SCROLLBARS_BOTH 필드가,true 로 설정되어 있어도,TextArea 가, 수직 스크롤 바 밖에 표시되지 않는 경우가 있다

4636311 : 릴리스 1.3. 1 및 1.4 상에서 Runnable 를 실행하면(자), 모덜 다이얼로그가 행업 하는 경우가 있다

4385243 : ANSI code page (Hindi 등)를 포함하지 않는 Microsoft Windows 로케일에 텍스트를 입력할 수 없다

1.4. 1 버그의 수정

4690831 : 게임 애플릿이 Internet Explorer 에서는 정상적으로 재draw 할 수 없다

4627627 : 포커스 traversal 키가 awt.properties 로부터 Preferences API 에 이동한다

4636548 /4639735 : Microsoft Windows 2000 으로 스크린 세이버가 기동하고 있는 경우 릴리스 1.4 가 크래쉬 한다

4379138 : 몇개의 대드 키의 키 이벤트에 대한 리눅스상의 문제

4627542 : Swing 어플리케이션은, Linux에서는 인터내셔널 키보드를 지원하지 않는다

4395157 : Linux 의 1.3 에서는, 애플릿으로 「%」를 입력할 수 없다

4669873 : Microsoft Windows 의 호퍼 베타에 보고되고 있는, 드래그＆드롭의 버그. 드래그＆드롭중에 어플리케이션이 단시간 다운 당한다.

새로운 포커스 하부조직

이 변경에 관련하는 버그 추적 리포트: 4290675 .

지금까지의 포커스 아키텍쳐(architecture)는, 포커스 하부조직에 새롭게 옮겨졌습니다. 새로운 포커스 하부조직은, 플랫폼이 다르기 위해서(때문에) 생기는 포커스 관련의 버그나, AWT 와 Swing 컴퍼넌트와의 비호환성에 대응하고 있습니다. 상세한 것에 대하여는,「포커스 모델 스펙」 을 참조해 주세요.

여기로부터 javadoc 를 참조해 주세요.

헷드레스사포트

이 변경에 관련하는 버그 추적 리포트: 4281163 .

메인프레임이나 전용 서버와 같은 환경에서는, 많은 경우, 디스플레이, 키보드, 마우스를 지원하고 있습니다. GraphicsEnvironment 의 신규 메소드 isHeadless 및 isHeadlessInstance 에 의해, 헷드레스사포트가 가능하게 되어 있습니다. 이러한 메소드에서는, 디스플레이, 키보드, 마우스가 그래픽 환경에서 지원될지 어떨지를 나타냅니다.

헷드레스에는 다음과 같은 API 의 변경이 있습니다.

(*)Applet,Button,Checkbox, Choice,FileDialog,Label, List,Menu,MenuBar, MenuComponent,MenuItem, PopupMenu,Scrollbar, ScrollPane,TextArea,TextComponent, Frame,Window,Dialog, JApplet,JFrame,JWindow, JDialog,TextField. Canvas및Panel는, 빈 상태(empty)의 피어를 할당해 경량 컴퍼넌트로서 취급할 수가 있으므로, 이러한 예외를 throw 할 필요가 없습니다.

헷드레스를 구현한 환경을 실행하려면 ,java 커멘드행에 다음의 프로퍼티을 지정합니다. 

  -Djava.awt.headless=true
이 프로퍼티이 설정되지 않고, 디스플레이, 키보드, 및 마우스가 지원되지 않는 경우, 디폴트에서는 헷드레스 구현이 사용됩니다.

예외가 올바르고 캐치 되도록(듯이), 원시 코드로 헷드레스를 체크할 필요가 있습니다. 예를 들어, 헷드레스를 구현하기 이전의 Foo 클래스의 구현은 다음과 같습니다. 

class Foo {
  static Choice c = new Choice();  // could throw HeadlessException
}
헷드레스 구현 후의 새로운 Foo 의 구현은, static 블록에 다음과 같이 기술합니다. 
class Foo {
  static Choice c;
  static {
    try {
      c = new Choice();
    catch (HeadlessException e) {
        ...
    }
  }
}

새로운 전화면 배타 모드 API

이 변경에 관련하는 버그 추적 리포트: 4189326 .

새로운 전화면 배타 모드의 API 는, 윈도우 시스템을 일시정지해 화면에 직접 draw 할 수 있는 고성능 그래픽스를 지원합니다. 전화면 모드란, AWT 프레임,윈도우,다이얼로그를 화면에 맞추어 넓힐 뿐(만큼)의 기능과는 완전히 달라, 비데오메모리의 내용을 어플리케이션으로 완전하게 제어하는 그래픽 모드입니다. 어플리케이션측에서 그래픽 카드로 draw 내용, draw 방법, draw 타이밍을 지시합니다. 이 모드는 언제나 이용할 수 있는 것은 아닙니다. operating system에 따라서는, 전혀 구현할 수 없는 것도 있습니다. 또, operating system안에는, 그래픽 카드가 이 기능을 지원하고 있는 경우에게만 이용할 수 있는 것도 있습니다. 다만, 이 모드는 성능에 큰 영향을 주므로, Windows 에서는 하드웨어의 page-flipping 기능을 유효하게 해 둘 필요가 있습니다.

전화면 배타 API 모드의 사용법과 코드예에 대해서는,여기를 참조해 주세요.

API 의 변경

Windows NT 에서의 비디오 드라이버의 Sync Out of Range 에러

이 변경에 관련하는 버그 추적 리포트: 4452207 .

Intel 810 그래픽 콘트롤러 탑재의 Dell Optiplex GX110 로 Windows NT 를 사용하고 있는 경우에, 표시 모드를 고해상도(�여러 차례 변경하면(자), 비디오 드라이버로부터 「sync out of range」라고 하는 메세지가 표시되는 일이 있습니다. 이것은, (DirectX) 비디오 드라이버의 버그가 원인입니다. 이 문제에 대해서는, 다음과 같은 몇개의 회피 방법이 있습니다.

비장식 프레임

이 변경에 관련하는 버그 추적 리포트: 4038769 .

어플리케이션에 따라서는, 네이티브 프레임 장식이 없는 것이 좋은 경우가 있습니다. 예를 들어, 다양한 플랫폼에서 실행되는 어플리케이션으로 같은 Look＆Feel 가 필요한 경우나, 네이티브의 operating system 기능을 사용해 최종 사용자가 어플리케이션에 개입하는 것을 프로그래머가 바라지 않는 경우입니다.

이 릴리스에서는, Java 어플리케이션을 사용해 프레임 장식의 작성 기능을 무효로 할 수 있습니다. 비장식 프레임 모드를 온으로 하면(자), 네이티브인 타이틀 바, 시스템 메뉴, 경계, 또는 operating system에 의존하는 그 외의 네이티브인 화면 컴퍼넌트는 표시되지 않습니다. AWT 와 Swing 컴퍼넌트는 투과적으로 기능합니다.

java.awt.Frame 의 변경점: 

    public void setUndecorated(boolean undecorated) 

    public boolean isUndecorated()

java.awt.Dialog 의 변경점: 

    public void setUndecorated(boolean undecorated) 

    public boolean isUndecorated()

마우스 휠의 지원

이 변경에 관련하는 버그 추적 리포트: 4289845 .

마우스 휠과는 중앙의 버튼 대신에 휠이 있어서 , 마우스 휠에 의한 스크롤 기능이 Java 의 편입 지원에 새롭게 더해졌습니다. The java.awt.event.MouseWheelEvent 클래스는, Java 어플리케이션으로 마우스 휠의 스크롤을 심리스에 지원하는 것을 가능하게 합니다. 이 때, 재컴파일은 필요 없습니다. 또, 새로운 인터페이스 java.awt.event.MouseWheelListener 를 사용해 마우스 휠의 동작을 커스터마이즈 할 수도 있습니다.

Linux 로 마우스 휠을 사용하는 경우는,여기를 참조해 주세요.

Frame 의 프로그래밍 줌

이 변경에 관련하는 버그 추적 리포트: 4071554 .

지금까지는,Frame 를 프로그램상에서 줌 (최대화) 하는 방법은 없었습니다. 이 릴리스에서는, 이 기능이 추가되었습니다.

신규 인터페이스 java.awt.event.WindowStateListener 가 도입되고 있습니다.

java.awt.Frame 의 변경점: 

    public static final int MAXIMIZED_HORIZ; 

    public static final int MAXIMIZED_VERT; 

    public static final int MAXIMIZED_BOTH; 

    public synchronized void setMaximizedBounds(Rectangle bounds) 

    public Rectangle getMaximizedBounds() 

    public synchronized void setExtendedState(int state) 

    public synchronized int getExtendedState()

java.awt.event.WindowEvent 의 변경점: 

    public static final int WINDOW_STATE_CHANGED; 

    public WindowEvent(Window source, int id, Window opposite, int oldState, int newState) 

    public WindowEvent(Window source, int id, int oldState, int newState) 

    public int getOldState() 

    public int getNewState()

java.awt.AWTEvent 의 변경점: 

    public final static long WINDOW_STATE_EVENT_MASK;

java.awt.Toolkit 의 변경점: 

    public boolean isFrameStateSupported(int state)  throws HeadlessException

java.awt.Window 의 변경점: 

    public synchronized void addWindowStateListener(WindowStateListener l) 

    public synchronized void removeWindowStateListener(WindowStateListener l) 

    public synchronized WindowStateListener[] getWindowStateListeners() 

    protected void processWindowStateEvent(WindowEvent e)

java.awt.event.WindowAdapter 의 변경점: 

    public void windowStateChanged(WindowEvent e)

java.awt.AWTEventMulticaster 의 변경점: 

    public static WindowStateListener add(WindowStateListener a, WindowStateListener b) 

    public static WindowStateListener remove(WindowStateListener l, WindowStateListener oldl)

사이즈 변경시의 동적인 레이아웃

이 변경에 관련하는 버그 추적 리포트: 4077991 .

지금까지는, 어느 플랫폼으로도 윈도우의 크기의 동적인 변경은 지원되고 있지 않았습니다. 예를 들어 Windows NT 에서는 크기의 정적인 변경을 「온」으로 하면(자), 드래그가 종료했을 때에만 레이아웃이 재계산되어, 윈도우의 크기가 변경되었습니다. 이 릴리스에서는, 이 기능이 수정되어 신규 데스크탑 프로퍼티 awt.dynamicLayoutSupported 가 추가되었습니다. 동적 레이아웃이 유효한 때는,Container 는 크기의 변경에 수반해 컴퍼넌트를 연속적으로 배치합니다. 무효인 때는, 크기의 변경이 종료한 다음에 레이아웃이 검증됩니다.

java.awt.Toolkit 의 API 의 변경점: 

    public void setDynamicLayout(boolean dynamic) 

    protected boolean isDynamicLayoutSet() 

    public boolean isDynamicLayoutActive()

컴퍼넌트 리스너 리스트에의 액세스

이 변경에 관련하는 버그 추적 리포트: 4290704 .

지금까지는, 기입해 가능한 모든 AWT 컴퍼넌트는 읽어낼 수도 있었습니다. 예를 들어, 컴퍼넌트 API 에는 기입해 전용의 프로퍼티은 없습니다. 이벤트 리스너는 완전한 예외였습니다. AWT 이벤트 리스너에는 다음과 같은 1 조의 메소드가 있어, JavaBeansTM 의 규칙에 따라 관리되고 있습니다. XXXEventListener 인터페이스를 구현하는 리스너의 addXXXListener 메소드와 removeXXXListener 메소드.

리스너 리스트 그 자체에의 액세스 기능은 제공되지 않았습니다. 리스너 리스트를 포함한 필드는 package private 로, 리스너 리스트의 내용을 되돌리는 메소드는 제공되지 않았습니다. 이것은 Swing 나 다른 AWT 클라이언트에 있어서의 문제의 원인이 되어 있었습니다.

버젼 1.3 의 Java 2 SDK 의 문제를 가볍게 하기 위해서,Component 에 getListeners 메소드를 추가해, 리스너 리스트를 정의한 Swing 클래스에도 추가했습니다. getListeners 메소드는, 클래스를 사용해 특정의 리스너 리스트를 지정합니다. 예를 들어,addFocusListener 에 의해 추가된 모든 리스너를 얻기 위해서(때문에)는, 다음과 같이 기술합니다. getListeners(FocusListener.class)

리스너 리스트를 공개하는 이 특정의 어프로치에 의해, AWT/Swing public API 전체의 변경을 최소한으로 할 수 있었습니다. 이것은 모든 JavaBeans 의 규칙으로 하기 위한 것은 아니고,addPropertyChangeListener("myProperty", myListener) 와 같은 단독의 프로퍼티에 추가할 수 있는 PropertyChangeListener 는 취급하지 않았습니다. 이 릴리스에서는, 이벤트 리스너에 액세스 할 수 있는, 보다 완성도의 높은 솔루션이 설계되고 있습니다. 개념상은, 다음의 2 점이 변경되고 있습니다.

신규 클래스 java.awt.event.AWTEventListenerProxy 가 있습니다.

java.awt.Toolkit 의 API 의 변경점: 

    public PropertyChangeListener[] getPropertyChangeListeners() 

    public synchronized PropertyChangeListener[] getPropertyChangeListeners(String propertyName) 

    public AWTEventListener[] getAWTEventListeners() 

    public AWTEventListener[] getAWTEventListeners(long eventMask)

드래그＆드롭의 변경점

이 변경에 관련하는 버그 추적 리포트: 4407057 및 4426750

Solaris 및 Linux 판의 Java 2 Standard Edition, SDK 1.3 에서는, 어플리케이션이 java.awt.dnd API 를 사용해 AWT 중량 Components 를 DragSource 로서 식별하지 않는 경우에서도, 마우스의 조절 버튼으로 디폴트의 드래그 동작을 나타내는 Component 가 몇개인가 있었습니다. 이러한 Component 는 Motif 피어를 사용해 구현되어 Motif 는 마우스의 조절 버튼의 드래그 동작을 디폴트로 이러한 피어에 제공합니다.

AWT 의 설계상의 문제와 Motif 라이브러리의 버그를 위해서(때문에), 이 디폴트의 동작은 안정성에 관한 다양한 문제의 원인이 되어 있습니다. 향후도 AWT 와 드래그＆드롭의 안정성을 계속 위험에 처하는 것보다 는, 이 기능을 구현하지 않고 명확하게 무효로 하는 편이 좋다고 판단했습니다.

그런데도 java.awt.dnd API 를 사용하면, 개발자는 어플리케이션의 Component 를 DragSource 라고 볼 수가 있습니다. 이것은 기능적이기도 해, 지원의 대상이기도 합니다. 이 어프로치는, 디폴트의 Motif 동작에 의존하는 것보다도, 항상 우수합니다. Solaris 와 Linux 만이 아니고, 모든 플랫폼에서 Component 의 드래그를 지원할 수 있기 때문입니다.

64 비트 대응의 Solaris 머신

이 변경에 관련하는 버그 추적 리포트: 4295833 .

64 비트의 Solaris 어플리케이션은, 32 비트는 아니고 64 비트를 사용해 메모리에 액세스 합니다. 이것에 의해, 가상 메모리의 용량을 늘려 대용량의 어플리케이션을 사용할 수 있는신음합니다. 이 릴리스의 AWT 는 64 비트까지 대응하고 있습니다. 자세한 것은,여기 를 참조해 주세요.

일관성이 없는 DLL 경고

이 변경에 관련하는 버그 추적 리포트: 4414004 .

아시아계 언어판의 Windows NT 도 인스톨 되고 있는 머신에 영문판의 VC++ 6.0 을 인스톨 했을 경우,TextArea 컴퍼넌트에 아시아계 언어판의 텍스트를 사용하면(자), 문자가 변하고가 발생합니다. 이 문제는, 2 바이트 대응의 Windows NT 가 동작하고 있는 머신에 Microsoft Exchange 또는 Microsoft Office 97 을 인스톨 해도 발생합니다. 이 문제는 일본어판의 Windows NT 로 보고되었습니다만, 중국어나 한국어판이라고 하는 비라틴계 언어판에서도 발생한다고 생각됩니다.

이 문제는, 프로그램의 인스톨시에 아시아계 언어판 Riched32.dll 가 영문판에 옮겨졌기 때문에 생겼습니다. Riched32.dll 를 아시아계 언어판에 옮겨놓으면(자), 문제는 해결합니다.

draw면 API 의 삭제

이 변경에 관련하는 버그 추적 리포트: 4293646 .

sun.awt.DrawingSurface API 가 삭제되었습니다. 지금까지 공표되었던 적은 없습니다만, 사용하고 있는 개발자도 있습니다. 이 API 의 기능은 JAWT 로 옮겨지고 있습니다. 자세한 것은,AWT Native Interface 에 있는 설명을 참조해 주세요.

멀티스크린의 지원에 필요한 윈도우의 중앙 배치 API

이 변경에 관련하는 버그 추적 리포트: 4463949 .

멀티 헤드 시스템으로 동작하는 Xinerama 대응의 어플리케이션으로 다양한 문제가 발생해, 버그 리포트가 작성되고 있습니다. 멀티 헤드 환경에서 경계의 작은 모니터를 사용하고 있는 경우는, 모니터 끼리가 서로 접촉해 , 그 결과 1 개(살)의 거대한 디스플레이와 같은 효과를 얻을 수 있습니다. 이 경우는, 「적절히」중앙 배치된 윈도우가 복수의 화면에 걸쳐 표시됩니다. 멀티 헤드 환경에서 일반적으로의 CRT 모니터를 사용하고 있는 경우는, 실제의 표시 영역 끼리의 사이에 수인치의 차이가 생깁니다. 이 경우, 윈도우를 드래그 할 수 없는 모니터 (Solaris 의 로그인 화면등)가 있는 경우는 특히, 복수의 화면에 걸치는 윈도우에 기묘한 효과가 발생합니다. 즉, Xinerama 환경의 어디를 중심으로 윈도우를 배치하는지를 지시할 방법이 없었습니다.

이 문제에 대처하기 위해(때문에), X 그룹에 API 가 추가되었습니다. 이 API 를 사용해, Xinerama 의 사용자는 윈도우 배치의 중심을 지정할 수 있어 Xinerama 대응 어플리케이션의 개발자는 적절히 코딩 할 수 있게 되었습니다.

이 릴리스 이전에는, 다음과 같이 디폴트의 GraphicsDevice 의 경계내에서 윈도우를 중앙 배치하고 있었습니다. 

    bounds = getDefaultScreenDevice(). getDefaultConfiguration(). getBounds();
    frame.setLocation(bounds / 2 - 윈도우 사이즈 / 2);
이 코드에 의해, Xinerama 시스템의 윈도우가 Xinerama 전체의 좌표 공간에 올바르고 중앙 배치되고 있었습니다.

이 릴리스 이후의 4356756 수정이 끝난 JDK 에서는, Xinerama 시스템의 윈도우는, primary 디스플레이안에 올바르고 중앙 배치되게 됩니다.

이것을 실현하기 위해서(때문에),getCenterPoint 메소드가 GraphicsEnvironment 에 추가되었습니다.

이 메소드는, 각종 플랫폼에서 다음과 같이 동작합니다.

JDK 1.4 로부터, 중앙 배치를 위한 올바른 코드는 다음과 같이 됩니다. 

    frame.setLocation(getCenterPoint() - 윈도우 사이즈 / 2);

GraphicsEnvironment 에 추가된 이제(벌써) 1 개의 메소드는 getMaximumWindowBounds 입니다. getCenterPoint 와 getMaximumWindowBounds 는 어느쪽이나, 헷드레스모드 때에 HeadlessException 를 throw 합니다.

새로운 InputEvent 키 수식자

이 변경에 관련하는 버그 추적 리포트: 4387938 및 4421515

지금까지,InputEvent 수식자는, 키보드와 mouse button에 대해서 같은 값을 가지고 있었습니다. 상황에 따라서는, 어느 키나 버튼이 밀렸는지를 구별할 수 없는 것이나, 동시에 복수 밀렸을 때에 판별할 수 없는 것이 있었습니다. 이러한 상황으로서는, 동시에 복수의 mouse button가 밀렸을 때나, 마우스 이벤트가 수식자에 의해 변경되었을 때등이 있습니다.

이 결함을 해결하기 위해서, 다음의 정수가 InputEvent 에 추가되었습니다.

다음의 메소드가 InputEvent 에 추가되었습니다.

MouseEvent 의 클래스 스펙이 갱신되었습니다. 다음의 정수도 MouseEvent 에 추가되었습니다.

다음의 메소드가 MouseEvent 에 추가되었습니다.

DragSourceDragEvent 에 새로운 getGestureModifiersEx 메소드가 추가되었습니다.

Choice 메뉴의 드롭 다운 동작의 변경점

이 변경에 관련하는 버그 추적 리포트: 4462677 .

Choice 드롭 다운 메뉴의 동작이, JDK 1.3. 1 에서 1.4 의 사이에 변경되었습니다. 1.3. 1 에서는, Choice 바의 어디를 클릭해도 드롭 다운 메뉴가 표시되었습니다. 1.4 에서는,Choice 바의 오른쪽에 있는 화살표를 클릭할 필요가 있습니다. Choice 바의 다른 부분을 클릭해도 아무것도 일어나지 않습니다. Choice 바의 기호도, 바로부터 화살표와 바를 조합한 것으로 변경되었습니다. 마지막으로, 드롭 다운 메뉴가 전개되었을 때, 부모의 밖에 나와 있는 부분을 클릭하면(자), 그 아래에 있는 어플리케이션이 전면에 표시됩니다. 다만, 이것은 Solaris 에서의 동작이며, Windows 에서는 다릅니다.

선택 컴퍼넌트는 레이아웃 매니저 제한으로 적합

이 변경에 관련하는 버그 추적 리포트: 4288285 .

1.4 보다 전의 릴리스에서는, AWT Choice 위젯는, 레이아웃 매니저가 지정한 사이즈를 무시하는 경우가 있었습니다. 이 릴리스에서는, 레이아웃 매니저의 제한에 따릅니다.

추천 되지 않는 Focus 메소드

이 변경에 관련하는 버그 추적 리포트: 4476300 .

이 릴리스로 도입된 새로운 포커스 하부조직에서는, AWT 및 Swing 의 고도의 어플리케이션으로 키보드 포커스를 취급하기 위해서(때문에), 새로운 아키텍쳐(architecture)와 용어가 도입되었습니다. 이 프로젝트 이전에는, 포커스 관련의 API 가 많고로 사용법과 용어에 무결성이 없고, 문서에도 미비가 있었기 때문에, 불완전한 설계의 UI 로 연결되어 있었습니다. 새로운 아키텍쳐(architecture)가 도입된 현재는, 이러한 API 의 쳐 특히 사용을 피해야 할 것이 있습니다.

다음의 정수와 메소드는 추천 되지 않게 되었습니다.

타임 스탬프를 필요로 하는 ActionEvent ( 및 그 외의 이벤트)

이 변경에 관련하는 버그 추적 리포트: 4434193 .

새로운 포커스 아키텍쳐(architecture)에는, 앞치는 것 기구도 포함되어 있습니다. 이 기구에서는, 어느 KeyEvent 로 포커스 이동이 개시되면(자), 이동이 완료할 때까지, 후속의 KeyEvent 는 전달되지 않게 됩니다. 이 기능의 설계는, 각종 이벤트의 UTC 타임 스탬프에 근거하고 있습니다. 이동을 개시한 이벤트보다 후의 타임 스탬프를 가지는 이벤트는 이동의 기다리는 행렬에 넣어집니다만, 그것보다 전의 타임 스탬프를 가지는 이벤트는 넣을 수 있지 않습니다.

이 기능을 실현하기 위해서(때문에), 포커스 코드에서는, 현재 처리중의 이벤트의 타임 스탬프를 항상 감시하고 있습니다. 이 처리중에 포커스 이동이 개시되었을 경우는, 그 타임 스탬프를 사용할 수 있습니다. 다만, 현재 처리중의 이벤트에 타임 스탬프가 없는 경우는, 시스템의 현재 시각이 사용됩니다. 현재 시각을 사용하는 경우, 일반적으로 이벤트가 실제로 발생했을 때 각보다 꽤 진행되고 있기 (위해)때문에, 실제로는 도움이 되지 않습니다. 결과적으로, 앞치는 것 기구는 실패해, 포커스 이동이 완료하기 전에 KeyEvent 가 전달됩니다.

ActionEvent 는, 기가 되는InputEvent 에 대응해 생성되는, 고레벨의 세만틱이벤트입니다. InputEvent 에는 타임 스탬프를 관련지을 수 있고 있었습니다만,ActionEvent 는 타임 스탬프를 가지고 있지 않았습니다. 따라서, 타임 스탬프를 포함할 수 있도록(듯이) ActionEvent API 가 확장되었습니다. 또, 구현도 갱신되어ActionEvent 의 타임 스탬프와 기반이 되는 InputEvent 의 타임 스탬프가 일치하게 되었습니다.

다음의 메소드가 ActionEvent 에 추가되었습니다.

다음의 ActionEvent 메소드가 변경되었습니다.

getWhen 메소드가 InvocationEvent 에 추가되었습니다.

InvocationEvent 의 InvocationEvent(Object, Runnable) 생성자 과 InvocationEvent(Object, Runnable, Object, boolean) 생성자 이 변경되었습니다.

새로운 InputMethodEvent(Component, int, long, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo) 생성자 이 InputMethodEvent 에 추가되었습니다. getWhen 메소드도 추가되고 있습니다.

다음의 InputMethodEvent 생성자 이 변경되었습니다.

마지막으로, 다음의 메소드가 EventQueue 에 추가되었습니다.

Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.


코멘트의 송부처:java-awt@java.sun.com 		Sun