JavaTM 2 SDK, v1.4 での AWT の拡張 |
ドキュメントの目次 |
バージョン 1.4 の Java 2 SDK では、次の AWT の機能が追加されています。新しいフォーカスサブシステム
推奨されない Focus メソッド
タイムスタンプを必要とする ActionEvent (およびその他のイベント)
ヘッドレスサポート
マルチスクリーンのサポートに必要なウィンドウの中央配置 API
新しい全画面排他モード API
Windows NT でのビデオドライバの Sync Out of Range エラー 非装飾フレーム
マウスホイールのサポート
Frame
のプログラミングズーム
サイズ変更時の動的なレイアウト
コンポーネントリスナリストへのアクセス
ドラッグ&ドロップの変更点
現在のウィンドウマネージャを明確にする
64 ビット対応の Solaris
一貫性のない DLL 警告
DrawingSurface
API の削除
新しい InputEvent キー修飾子
Choice メニューのドロップダウン動作の変更点
新しいフォーカスサブシステムヘッドレスサポートこの変更に関連するバグ追跡レポート: 4290675.
これまでのフォーカスアーキテクチャは、フォーカスサブシステムに新しく置き換わりました。新しいフォーカスサブシステムは、プラットフォームが異なるために生じるフォーカス関連のバグや、AWT と Swing コンポーネントとの非互換性に対応しています。 詳細については、「フォーカスモデル仕様」を参照してください。
ここから javadoc を参照してください。
この変更に関連するバグ追跡レポート: 4281163.
メインフレームや専用サーバのような環境では、多くの場合、ディスプレイ、キーボード、マウスをサポートしていません。
GraphicsEnvironment
の新規メソッドisHeadless
およびisHeadlessInstance
により、ヘッドレスサポートが可能になっています。 これらのメソッドでは、ディスプレイ、キーボード、マウスがグラフィック環境でサポートされるかどうかを示します。ヘッドレスには次のような API の変更があります。
- 新しい public exception クラスである
java.awt.HeadlessException
が導入されています。 これは、RuntimeException
から派生したUnsupportedOperationException
から派生しています。これにより、新しい例外をスローするメソッドの既存の実装でシグニチャを変更する必要がなくなります。- 次の 2 つの新しいメソッドが
java.awt.GraphicsEnvironment
に追加されています。public static boolean isHeadless() public boolean isHeadlessInstance()- ツールキットが実装されてもディスプレイ、キーボード、マウスがサポートされない場合、
Applet
のコンストラクタと重量コンポーネント (*) はすべてHeadlessException
をスローするように変更されています。 すべてのコンストラクタの javadoc タグは、すべてこのRuntimeException
を反映するように変更されています。Toolkit
とGraphicsEnvironment
のメソッドのうち、フォント、イメージング、および印刷を除く多くのメソッドが変更されて、ディスプレイ、キーボード、マウスがサポートされない場合にHeadlessException
をスローするようになりました。 このようなメソッドの javadoc タグはすべてこのRuntimeException
を反映するように変更されています。- ディスプレイ、キーボード、マウスがサポートされていないために影響を受けるその他のメソッドは、
HeadlessException
をスローするように変更されています。isHeadless
が true を返す場合のみ、HeadlessException
がスローされます。すべての javadoc コメントでこれを明記するようにしてください。(*)
Applet
、Button
、Checkbox
、Choice
、FileDialog
、Label
、List
、Menu
、MenuBar
、MenuComponent
、MenuItem
、PopupMenu
、Robot
、Scrollbar
、ScrollPane
、TextArea
、TextComponent
、Frame
、Window
、Dialog
、JApplet
、JFrame
、JWindow
、JDialog
、およびTextField
、Canvas
およびPanel
は、空のピアを割り当てて軽量コンポーネントとして扱うことができるので、このような例外をスローする必要がありません。ヘッドレスを実装した環境を実行するには、
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) { ... } } }Windows NT でのビデオドライバの Sync Out of Range エラーこの変更に関連するバグ追跡レポート: 4189326.
新しい全画面排他モードの API は、ウィンドウシステムを一時停止して画面に直接描画できる高性能グラフィックスをサポートします。 全画面モードとは、AWT
フレーム
、ウィンドウ
、ダイアログ
を画面にあわせて広げるだけの機能とはまったく異なり、ビデオメモリの内容をアプリケーションで完全に制御するグラフィックモードです。 アプリケーション側でグラフィックカードに描画内容、描画方法、描画タイミングを指示します。 このモードはいつも利用できるわけではありません。 オペレーティングシステムによっては、まったく実装できないこともあります。 また、オペレーティングシステムの中には、グラフィックカードがこの機能をサポートしている場合にのみ利用できるものもあります。ただし、このモードは性能に大きな影響を与えるので、Windows ではハードウェアの page-flipping 機能を有効にしておく必要があります。全画面排他 API モードの使い方とコード例については、ここを参照してください。
API の変更
- 新しい public final クラス
java.awt.DisplayMode
が導入されています。java.awt.GraphicsDevice
の変更点:public void setFullScreenWindow(Window w) public Window getFullScreenWindow() public boolean isDisplayChangeSupported() public void setDisplayMode(DisplayMode dm) public DisplayMode getDisplayMode() public DisplayMode[] getDisplayModes()- ビデオバッファを直接コントロールするアルゴリズムは、新規クラス
java.awt.image.BufferStrategy
の内部に実装されました。- 新規クラス
java.awt.BufferCapabilities
を使ってバッファストラテジを作成することができます。 同様に、新規クラスjava.awt.ImageCapabilities
を使って、特定の構成のイメージ機能を定義することができます。- アプリケーションプログラマは、
Canvas
またはWindow
からバッファストラテジを作成および使用できます。 protected 内部クラスとしてサポートされるバッファストラテジには次の 2 つがあります。java.awt.Component.FlipBufferStrategy
とjava.awt.Component.BltBufferStrategy
です。createBufferStrategy
メソッドが呼び出されると、この 2 つの内部クラスのどちらかがCanvas
またはWindow
で使用されます。どちらが使用されるのかは、(ストラテジがある場合は) ストラテジの作成時に提供されるBufferCapabilities
オブジェクトによって決まります。 特定のコンポーネントで使用されるバッファストラテジを取得するには、getBufferStrategy
メソッドを使います。この変更に関連するバグ追跡レポート: 4452207.
Intel 810 グラフィックコントローラ搭載の Dell Optiplex GX110 で Windows NT を使用している場合に、表示モードを高解像度にして複数回変更すると、ビデオドライバから「sync out of range」というメッセージが表示されることがあります。 これは、(DirectX) ビデオドライバのバグが原因です。 この問題に対しては、次のようないくつかの回避方法があります。
- コマンド行に
-Dsun.java2d.noddraw=true
を指定して DirectDraw を無効にする- このハードウェアで実行されるプログラムの存続期間中にディスプレイ解像度を複数回変更しない
- このハードウェアでは次の表示モードを禁止する
1152 X 864 8 85 1152 X 864 16 85 1152 X 864 24 85 1280 X 1024 8 70,72,75,85 1280 X 1024 16 70,72,75,85 1280 X 1024 24 70,75,85 無効色 (期待どおりに表示されない色) 1024 X 768 8 60,70,72,75,85この変更に関連するバグ追跡レポート: 4038769.
アプリケーションによっては、ネイティブフレーム装飾のない方がよい場合があります。 たとえば、さまざまなプラットフォームで実行されるアプリケーションで同じ Look&Feel が必要な場合や、ネイティブのオペレーティングシステム機能を使ってエンドユーザがアプリケーションに介入することをプログラマが望まない場合です。
このリリースでは、Java アプリケーションを使ってフレーム装飾の作成機能を無効にすることができます。非装飾フレームモードをオンにすると、ネイティブなタイトルバー、システムメニュー、ボーダ、またはオペレーティングシステムに依存するその他のネイティブな画面コンポーネントは表示されません。 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 の組み込みサポートに新しく加わりました。
java.awt.event.MouseWheelEvent
クラスは、Java アプリケーションでマウスホイールのスクロールをシームレスにサポートすることを可能にします。このとき、再コンパイルは必要ありません。 また、新しいインタフェースjava.awt.event.MouseWheelListener
を使ってマウスホイールの動作をカスタマイズすることもできます。Linux でマウスホイールを使用する場合は、ここを参照してください。
- スクロール動作
- スクロールバーが表示されていて、かつ、スクロールする
Component
に一度に表示できる量以上の内容がある場合 (スクロールサムがスクロールバー全体を占領しないような場合) に、スクロールバーは「スクロール可能」と見なされます。- スクロールバーが表示されていても、スクロールできない場合もあります。 通常、この状態は、スクロールバーを常に表示する設定になっているときに発生します。
- マウスホイールでスクロールする対象のスクロールバーは、次のように判定されます。
- スクロール可能なスクロールバーが 1 つだけある場合は、そのスクロールバーがスクロール対象となる
- 水平スクロールバーと垂直スクロールバーが両方ともスクロール可能な場合は、垂直スクロールバーがスクロール対象となる
- ホイールによるスクロールをすべて無効にするには、
setWheelScrollEnabled(false)
を使用します。- ホイールを上に (自身から遠ざかる方向に) 回すと、垂直スクロールバーは上に、水平スクロールバーは左にスクロールします。 ホイールを下に (自分の方に) 回すと、反対の方向にスクロールします。
- スクロールサムがスクロールバーの端にあるときはスクロールしません。
- 重量サポート
- スクロールバーが統合されているネイティブピアには、独自にマウスホイールのスクロールを扱うものがあります。 Windows の例では
TextArea
、Choice
、FileDialog
、List
があります。 このようなコンポーネントでは、ネイティブピアによってマウスホイールのスクロールが制御されます。- ネイティブのマウスホイールの動作を継承しない
Component
は、MouseWheelEvent
が有効になっているContainer
が見つかるまでContainer
階層にマウスホイールのイベントを伝えます。 通常、これがScrollPane
です。 マウスホイールのイベントは、MouseWheelEvent
が有効になっているComponent
に伝えられます。- または、クライアントプログラマが
MouseWheelListener
を追加して、マウスがComponent
上にあるときにマウスホイールを動かした場合の動作をカスタマイズすることもできます。 マウスホイールのイベントをネイティブで処理できるComponent
の場合、クライアントはマウスホイールのイベントを使ってネイティブな処理を避けることができます。java.awt.ScrollPane
は、デフォルトでMouseWheelEvent
が有効になるように変更されています。ScrollPane
がMouseWheelEvent
を受け取ると、内部のComponent
が正しくスクロールされます。 この機能は、新規メソッドsetWheelScrollingEnabled
で無効にすることもできます。
軽量サポート
- 軽量コンポーネントは、
MouseWheelListener
を持つ最初の先祖にマウスホイールのイベントを伝えます。MouseWheelListener
をJComponent
に追加してカスタムイベント処理を行うことができます。- 表示されたコンポーネントが正しくスクロールできるように
javax.swing.JScrollPane
が変更されています。java.awt.ScrollPane
と同じように、setWheelScrollingEnabled
を使用して、この機能を無効にすることもできます。
- 新しい API
API では、マウスホイールをサポートするため、すでに説明した新規クラスや新規インタフェース以外にも次の点が変更されています。
java.awt.AWTEvent
の変更点:public final static long MOUSE_WHEEL_EVENT_MASK = 0x20000;java.awt.AWTEventMulticaster
の変更点:public void mouseWheelMoved(MouseWheelEvent e) public static MouseWheelListener add(MouseWheelListener a, MouseWheelListener b) public static MouseWheelListener remove(MouseWheelListener l, MouseWheelListener oldl)java.awt.Component
の変更点:public synchronized void addMouseWheelListener(MouseWheelListener l) public synchronized void removeMouseWheelListener(MouseWheelListener l)java.awt.ScrollPane
の変更点:public void setWheelScrollingEnabled(boolean handleWheel) public boolean isWheelScrollingEnabled()java.awt.Robot
の変更点:public synchronized void mouseWheel(int wheelAmt)- Linux でのマウスホイールのサポート
Linux でマウスホイールを認識させるには、
/etc/X11/XF86Config
ファイルに 2 つの変更を行う必要があります。 「ポインタ」セクションで次のような変更を行います。
次のコードを追加します。
ZAxisMapping 4 5プロトコルを次のように変更します。 「imps/2」 (お使いのホイールマウスによって異なります)
この変更に関連するバグ追跡レポート: 4071554.
これまでは、
Frame
をプログラム上でズーム (最大化) する方法はありませんでした。 このリリースでは、この機能が追加されました。新規インタフェース
java.awt.event.WindowStateListener
が導入されています。
java.awt.Frame
の変更点:public static final int MAXIMIZED_HORIZ = 2; public static final int MAXIMIZED_VERT = 4; public static final int MAXIMIZED_BOTH = MAXIMIZED_VERT | MAXIMIZED_HORIZ; 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 = 9 + WINDOW_FIRST; 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 = 0x40000;
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 processItemEvent(ItemEvent 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
は大きさの変更に伴ってコンポーネントを連続的に配置します。 無効なときは、大きさの変更が終了した後でレイアウトが検証されます。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 点が変更されています。
getFooListeners
メソッドを AWT クラスと Swing クラスの add/remove 規則に追加- 単独プロパティを待機するメソッドを含む
PropertyChangeListener
およびVetoableChangeListener
のサポート。新規クラスjava.util.EventListenerProxy
を使用します。新規クラス
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
のドラッグをサポートできるからです。この変更に関連するバグ追跡レポート: 4384023.
AWT は現在どのウィンドウマネージャが実行されているのかを判断するヒントを検索し、この情報を使って特定のウィンドウマネージャに合わせたコードを実行します。 ただし、以前のバージョンでは、この情報が無効になるとバグレポートにあるような非常に奇妙な効果を生じるバグが発生しました。
このバグは今回のリリースで修正されましたが、難しい副作用が生じる可能性もあるので注意が必要です。
古いコードでは、特定のアトムがインターン (X Window システムにおける、Intern Atom の呼び出し) されているかどうかを確認して、現在のウィンドウマネージャを単純に検出していました。これは、特定のウィンドウマネージャがそうしたアトムをインターンするという前提に基づいているためです。 新しい実装ではより洗練された確認方式を採用しています。確認の一部として、古いコードが検索するのと同じアトムをインターンします。 その結果、この訂正された JDK を実行すると、古いビルドの JDK に混乱が生じます。 たとえば、古いコードがテストする最初のウィンドウマネージャは Enlightenment (アトム
ENLIGHTENMENT_COMMS
) です。 新しいコードによってこのアトムが保持されると、古いコードは新しいコードが Enlightenment の下で実行されていると見なします。現在のウィンドウマネージャが Enlightenment ではない場合、Enlightenment 用のコードが間違った結果を作成するたびに、好ましくない影響が発生します。残念ながらこのような副作用は避けることができません。 修正されたビルドを実行した後で、他の古いビルドを実行する必要がある場合、X サーバをリセットして、古いコードを混乱させる余分なアトムをすべて取り除く必要があります。
X サーバの再起動Unix で X サーバを再起動するには、X セッションを終了する必要があります。 Win 32 では、通常、X サーバのメニューには「リセット」という項目があります。
一貫性のない DLL 警告この変更に関連するバグ追跡レポート: 4295833
64 ビットの Solaris アプリケーションは、32 ビットではなく 64 ビットを使ってメモリにアクセスします。これにより、仮想メモリの容量を増やして大容量のアプリケーションが使用できるようなります。 このリリースの AWT は 64 ビットまで対応しています。 詳細は、ここ を参照してください。
描画面 API の削除この変更に関連するバグ追跡レポート: 4414004.
アジア系言語版の Windows NT もインストールされているマシンに英語版の VC++ 6.0 をインストールした場合、
TextArea
コンポーネントにアジア系言語版のテキストを使用すると、文字化けが発生します。 この問題は、2 バイト対応の Windows NT が動作しているマシンに Microsoft Exchange または Microsoft Office 97 をインストールしても発生します。 この問題は日本語版の Windows NT で報告されましたが、中国語や韓国語版といった非ラテン系言語版でも発生すると思われます。この問題は、プログラムのインストール時に アジア系言語版 Riched32.dll が英語版に置き換わったために生じました。 Riched32.dll をアジア系言語版に置き換えると、問題は解決します。
マルチスクリーンのサポートに必要なウィンドウの中央配置 APIこの変更に関連するバグ追跡レポート: 4293646.
sun.awt.DrawingSurface
API が削除されました。 これまで公表されたことはありませんが、使用している開発者もいます。 この API の機能は JAWT に置き換えられています。 詳細は、AWT 1.3 リリースノートの AWT Native Interface にある説明を参照してください。新しい InputEvent キー修飾子この変更に関連するバグ追跡レポート: 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 システムのウィンドウは、プライマリディスプレイの中に正しく中央配置されるようになります。
これを実現するために、
getCenterPoint
メソッドがGraphicsEnvironment
に追加されました。このメソッドは、各種プラットフォームで次のように動作します。
- Win32/Macintosh
これらのプラットフォームでは、すべてのモニタが単一の仮想座標空間に置かれます。 ただし、その中の 1 つが「プライマリ」ディスプレイとなります。プライマリディスプレイには、Win32 ではタスクバーが、Mac ではメニューバーが表示されます。 ここでは、getCenterPoint
はプライマリディスプレイの中心座標を返します。
- Xinerama 以外の X Window
各ディスプレイが独自の座標系を持っています。各ディスプレイの左上隅が 0.0 です。 この場合も、「プライマリ」ディスプレイが存在します。 ここでは、getCenterPoint
はプライマリディスプレイの中心座標を返します。
- Xinerama の X Window
Win32 と同様に、すべてのモニタが単一の仮想座標空間を共有します。 ただし、ユーザが X リソースを通してウィンドウ配置の中心を指定できます。 これらのリソースが設定されている場合、getCenterPoint
はその値を返します。 それ以外の場合は、仮想座標空間の中心点を返します。 (実際には、CDE がこれをデフォルトで設定するため、ほとんどの場合は設定されています。)JDK 1.4 から、中央配置のための正しいコードは次のようになります。
frame.setLocation(getCenterPoint() - ウィンドウサイズ / 2);
GraphicsEnvironment
に追加されたもう 1 つのメソッドはgetMaximumWindowBounds
です。getCenterPoint
とgetMaximumWindowBounds
はどちらも、ヘッドレスモードのときにHeadlessException
をスローします。Choice メニューのドロップダウン動作の変更点この変更に関連するバグ追跡レポート: 4387938 および 4421515
これまで、
InputEvent
修飾子は、キーボードとマウスボタンに対して同じ値を持っていました。 状況によっては、どのキーやボタンが押されたのかを区別できないことや、同時に複数押されたときに判別できないことがありました。 このような状況としては、同時に複数のマウスボタンが押されたときや、マウスイベントが修飾子によって変更されたときなどがあります。この欠陥を解決するために、次の定数が
InputEvent
に追加されました。
SHIFT_DOWN_MASK
CTRL_DOWN_MASK
META_DOWN_MASK
ALT_DOWN_MASK
ALT_GRAPH_DOWN_MASK
BUTTON1_DOWN_MASK
BUTTON2_DOWN_MASK
BUTTON3_DOWN_MASK
次のメソッドが
InputEvent
に追加されました。
MouseEvent
のクラス仕様が更新されました。 次の定数もMouseEvent
に追加されました。次のメソッドが
MouseEvent
に追加されました。
MouseEvent(Component source, int id, long when, int modifiers, int x, int y, int clickCount, boolean popupTrigger, int button)
getButton
getMouseModifiersText
DragSourceDragEvent
に新しいgetGestureModifiersEx
メソッドが追加されました。推奨されない Focus メソッドこの変更に関連するバグ追跡レポート: 4462677.
Choice
ドロップダウンメニューの動作が、JDK 1.3.1 から 1.4 の間で変更されました。 1.3.1 では、Choice バーのどこをクリックしてもドロップダウンメニューが表示されました。 1.4 では、Choice
バーの右にある矢印をクリックする必要があります。Choice
バーの他の部分をクリックしても何も起きません。Choice
バーの記号も、バーから矢印とバーを組み合わせたものに変更されました。 最後に、ドロップダウンメニューが展開されたとき、親の外に出ている部分をクリックすると、その下にあるアプリケーションが前面に表示されます。 ただし、これは Solaris での動作であり、Windows では異なります。タイムスタンプを必要とする ActionEvent (およびその他のイベント)この変更に関連するバグ追跡レポート: 4476300.
このリリースで導入された新しいフォーカスサブシステムでは、AWT および Swing の高度なアプリケーションでキーボードフォーカスを扱うために、新しいアーキテクチャと用語が導入されました。 このプロジェクト以前は、フォーカス関連の API の多くで使用法と用語に整合性がなく、ドキュメントにも不備があったために、不完全な設計の UI につながっていました。 新しいアーキテクチャが導入された現在では、これらの API のうち特に使用を避けるべきものがあります。
次の定数とメソッドは推奨されなくなりました。
javax.swing.FocusManager.FOCUS_MANAGER_CLASS_PROPERTY
javax.swing.FocusManager.disableSwingFocusManager()
javax.swing.FocusManager.isFocusManagerEnabled()
javax.swing.JComponent.requestDefaultFocus()
javax.swing.JComponent.isManagingFocus()
javax.swing.JComponent.setNextFocusableComponent(Component)
javax.swing.JComponent.getNextFocusableComponent()
java.awt.Component.isFocusTraversable()
java.awt.Component.hasFocus()
javax.swing.SwingUtilities.findFocusOwner(Component)
この変更に関連するバグ追跡レポート: 4434193.
新しいフォーカスアーキテクチャには、先打ち機構も含まれています。この機構では、ある
KeyEvent
でフォーカス移動が開始されると、移動が完了するまで、後続のKeyEvent
は配信されなくなります。 この機能の設計は、各種イベントの UTC タイムスタンプに基づいています。 移動を開始したイベントより後のタイムスタンプを持つイベントは移動の待ち行列に入れられますが、それより前のタイムスタンプを持つイベントは入れられません。この機能を実現するために、フォーカスコードでは、現在処理中のイベントのタイムスタンプを常に監視しています。 この処理中にフォーカス移動が開始された場合は、そのタイムスタンプを使用できます。 ただし、現在処理中のイベントにタイムスタンプがない場合は、システムの現在時刻が使用されます。 現在時刻を使用する場合、通常イベントが実際に発生した時刻よりもかなり進んでいるため、実際には役立ちません。 結果として、先打ち機構は失敗し、フォーカス移動が完了する前に
KeyEvent
が配信されます。この問題は
ActionEvent
で最も多く発生していました。ActionEvent
は、基となるInputEvent
に対応して生成される、高レベルのセマンティックイベントです。InputEvent
にはタイムスタンプが関連付けられていましたが、ActionEvent
はタイムスタンプを持っていませんでした。 したがって、タイムスタンプを格納できるようにActionEvent
API が拡張されました。また、実装も更新され、ActionEvent
のタイムスタンプと、基盤となるInputEvent
のタイムスタンプとが一致するようになりました。次のメソッドが
ActionEvent
に追加されました。次の
ActionEvent
メソッドが変更されました。
ActionEvent(Object source, int id, String command)
ActionEvent(Object source, int id, String command, int modifiers)
getWhen
メソッドがInvocationEvent
に追加されました。
InvocationEvent
のInvocationEvent(Object, Runnable)
コンストラクタとInvocationEvent(Object, Runnable, Object, boolean)
コンストラクタが変更されました。新しい
InputMethodEvent(Component, int, long, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo)
コンストラクタがInputMethodEvent
に追加されました。getWhen
メソッドも追加されています。次の
InputMethodEvent
コンストラクタが変更されました。
InputMethodEvent(Component, int, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo)
InputMethodEvent(Component, int, TextHitInfo, TextHitInfo)
.最後に、次のメソッドが
EventQueue
に追加されました。
Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.
コメントの送付先: java-awt@java.sun.com