時折、ネイティブ・プラット・フォームが原因で問題が発生することがあります。これをチェックするには、フォーカスに関係するネイティブ・イベントを調査します。

フォーカス対象のウィンドウがアクティブ化され、フォーカス対象のコンポーネントがネイティブ・フォーカス・イベントを受け取ることを確認してください。

Windowsプラットフォームのネイティブ・フォーカス・イベントは、次のとおりです。

• WM_ACTIVATE (トップ・レベル用)。WPARAMは、アクティブ化の際はWA_ACTIVE、非アクティブ化の際はWA_INACTIVEになります。

• WM_SETFOCUSおよびWM_KILLFOCUS (コンポーネント用)。

Windowsプラットフォームでは、合成フォーカス という概念が実装されています。つまり、フォーカス所有者コンポーネントはそのフォーカス可能状態をエミュレートするだけですが、実際のネイティブ・フォーカスはフォーカス・プロキシ・コンポーネントに設定されます。このコンポーネントは、キーとインプット・メソッドのネイティブ・メッセージを受け取り、それらをフォーカス所有者にディスパッチします。最新のJDKリリースでは、フレームまたはダイアログ・ボックスがフォーカス・プロキシとして機能します。現在は、所有されるウィンドウ内のコンポーネントだけでなく、すべての子コンポーネントのフォーカス・プロキシとしても機能します。単純なウィンドウは、ネイティブ・フォーカスを受け取ることは決してなく、その所有者のフォーカス・プロキシに依存します。ユーザーがこのメカニズムを意識することはありませんが、デバッグ時には考慮に入れるべきです。

Linuxオペレーティング・システム上のXToolkitでは、AWT自体がフォーカスを管理できるフォーカス・モデルを使用しています。このモデルでは、ウィンドウ・マネージャが直接トップレベル・ウィンドウに入力フォーカスを設定することはなく、代わりにWM_TAKE_FOCUSクライアント・メッセージのみを送信することで、フォーカスを設定すべきであることを示します。その後、トップレベル・ウィンドウへのフォーカス設定が可能な場合は、その設定がAWTによって明示的に行われます。

トップ・レベル内のコンポーネントがフォーカスを得ても、AWTはフォーカス・イベントの階層チェーンを生成しません。さらに、コンポーネントにマップされたネイティブ・ウィンドウはネイティブ・フォーカス・イベントを取得しません。LinuxプラットフォームではWindowsプラットフォームと同じく、AWTはフォーカス・プロキシ・メカニズムを使用します。したがって、コンポーネントのフォーカスはフォーカス・イベントの合成によって設定され、不可視のフォーカス・プロキシがネイティブ・フォーカスを保持します。

Windowオブジェクト(FrameオブジェクトでもDialogオブジェクトでもない)にマップされたネイティブ・ウィンドウには、override-redirectフラグが設定されます。したがって、ウィンドウ・マネージャはそのウィンドウに対し、フォーカス移動に関して通知しません。このウィンドウでフォーカスが要求されるのは、マウス・クリックへの応答としてだけです。このウィンドウはネイティブ・フォーカス・イベントを一切受け取りません。したがって、トレース可能なイベントは、フレームまたはダイアログ・ボックス上のFocusInまたはFocusOutイベントだけです。XToolkitでは、フォーカスの主な処理がJavaレベルで発生するため、フォーカスのデバッグがWToolkitの場合よりも単純になります。

Xウィンドウ・マネージャでサポートされているフォーカス・モデルは、次のとおりです。

• Click-to-focusは一般的に使用されているフォーカス・モデルです。(たとえば、Microsoft Windowsではこのモデルが使用されています。)

• Focus-follows-mouseは、マウスの下にあるウィンドウにフォーカスが移動するフォーカス・モデルです。

この項では、AWTのフォーカスに関連して発生する可能性のある問題および推奨される解決方法について説明します。

1. KDEを実行するLinux上のXToolkitでは、フレームのタイトルをクリックしても、2つのフレーム間で切り替えることができない。

   フレームの内側にあるコンポーネントをクリックすると、フォーカスが変更されます。

   解決方法: ウィンドウ・マネージャのバージョンをチェックし、3.0 以上にアップグレードします。

2. [Tab]/[Shift]+[Tab]でフォーカスを移動するためにKeyListenerを使用してフォーカスを管理しても、キー・イベントが現れない。

   解決方法: トラバーサル・キー・イベントをキャッチするには、Component.setFocusTraversalKeysEnabled(true)を呼び出してそれらのイベントを有効にする必要があります。

3. Window.setModalExclusionType(ModalExclusionType)でウィンドウがモーダル除外に設定される。

   その所有者であるフレームはモーダル・ブロックされています。この場合、ウィンドウもモーダル・ブロックされたままになります。

   解決方法: ウィンドウは、その所有者がフォーカスの取得を許可されていない場合はフォーカスされたウィンドウになれません。解決方法は、所有者をモーダリティから除外することです。

4. Windowsで、コンポーネントがフォーカスを要求し、同時にそのコンテナから削除される。

   java.lang.NullPointerException: null pDataがスローされる場合があります。

   解決方法: 例外のスローを避けるもっとも簡単な方法は、削除とフォーカス要求をEDT上で行うことです。もう1つのより複雑なアプローチは、フォーカス要求と削除を同期することです(これらのアクションをそれぞれ異なるスレッド上で実行する必要がある場合)。

5. あるコンポーネントがフォーカスを要求してすぐにフォーカス所有者が削除された場合、その削除されたコンポーネントの後のコンポーネントにフォーカスが移動する。

   たとえば、コンポーネントAがフォーカス所有者とします。コンポーネントBがフォーカスを要求し、その直後にコンポーネントAがそのコンテナから削除されます。フォーカスは最終的に、コンテナ内でコンポーネントAの後に配置されたコンポーネントCに移動し、コンポーネントBには移動しません。

   解決方法: この場合、フォーカス要求がコンポーネントAの削除前ではなく削除後に実行されるようにしてください。

6. Windowsで、非アクティブなフレーム内のウィンドウをalwaysOnTopに設定すると、そのウィンドウはキー・イベントを受け取れない。

   たとえば、フレームが1つと、そのフレームが所有するウィンドウが1つ表示されているとします。フレームがアクティブでないため、ウィンドウはフォーカスされません。その後、ウィンドウをalwaysOnTopに設定します。ウィンドウはフォーカスを取得しますが、その所有者は非アクティブなままです。したがって、ウィンドウはキー・イベントを受け取れません。

   解決方法: ウィンドウをalwaysOnTopに設定する前に、フレームを前面に移動します(Frame.toFront()メソッド)。

7. スプラッシュ画面が表示され、そのスプラッシュ画面のウィンドウが閉じた後でフレームが表示されると、そのフレームはアクティブ化されない。

   解決方法: フレームを表示した後で(Frame.setVisible(true)メソッド)、フレームを前面に移動します(Frame.toFront()メソッド)。

8. WindowFocusListener.windowGainedFocus(WindowEvent)メソッドがフレームの直近のフォーカス所有者を返さない。

   たとえば、あるフレームがフォーカスされたウィンドウであり、そのコンポーネントの1つがフォーカス所有者であるとします。別のウィンドウがクリックされたあと、このフレームが再度クリックされます。WINDOW_GAINED_FOCUSがフレームに送信され、WindowFocusListener.windowGainedFocus(WindowEvent)メソッドが呼び出されます。ただし、このコールバックの内部では、Frame.getMostRecentFocusOwner()からnullが返されるため、フレームの直近のフォーカス所有者を確認できません。

   解決方法: WindowListener.windowActivated(WindowEvent)コールバックの内部では、フレームの直近のフォーカス所有者を取得できます。ただし、この時点までにフレームがフォーカスされたウィンドウになっているのは、フレームが所有するウィンドウが1つも存在しない場合だけです。

   ノート:

   このアプローチは、ウィンドウでは機能せず、フレームまたはダイアログ・ボックスでのみ機能します。

9. Component.setEnabled(false)でウィンドウを無効にしても、完全にフォーカス不可能な状態にならない。

   解決方法: Component.setEnabled(false)またはComponent.setFocusable(false)を呼び出すことで設定された状態が、そのすべてのコンテンツでもフォーカス不可能な状態として維持されるとは仮定しないでください。代わりに、Window.setFocusableWindowState(boolean)メソッドを使用します。

• すべてのDataFlavorインスタンスの出力
• 受信されたデータの出力
  リモート・デバッグに代わる方法として、遅延なしで出力するSystem.err.println()関数があります。

この項では、AWTのデータ転送操作で頻繁に発生する問題を説明し、そのトラブルシューティング方法を提示します。

1. 大量のデータをクリップボードからペーストするのに時間がかかりすぎる。

   Clipboard.getContents()関数を使ってペースト操作を行うと、アプリケーションが少しの間、ハング・アップすることがあります(特にペースト対象データの提供元がリッチ・アプリケーションである場合)。

   Clipboard.getContents()関数は、使用可能なすべてのタイプ(いくつかのテキスト・タイプやイメージ・タイプなど)に含まれるクリップボード・データを取得しますが、これはコストが高く、不要である可能性があります。

   解決方法: Clipboard.getData()メソッドを使って特定のデータのみをクリップボードから取得します。1つのタイプまたは少数のタイプのみのデータが必要な場合は、getContents()のかわりに次のいずれかのClipboardメソッドを使用してください。

   • DataFlavor[] getAvailableDataFlavors()

   • boolean isDataFlavorAvailable(DataFlavor flavor)

   • Object getData(DataFlavor flavor)

2. JavaアプリケーションでDnD操作にTransferable.getTransferData()を使用すると、ドラッグに長い時間がかかるように思われる。

   転送データの初期化を必要な場合にのみ行えるよう、Transferable.getTransferData()内に初期化コードが配置されました。

   Transferableデータの生成コストは高く、DnD操作中にTransferable.getTransferData()が複数回呼び出されるため、速度が低下します。

   解決方法: Transferableデータをキャッシュに入れて、一度しか生成されないようにします。

3. JavaアプリケーションとGNOME/KDEデスクトップやファイル・ブラウザとの間でファイルを転送できない。

   Windowsや一部のウィンドウ・マネージャでは、転送ファイルのリストはDataFlavor.javaFileListFlavorデータ・タイプとして表現できます。しかし、すべてのウィンドウ・マネージャがファイルのリストをこの形式で表現するわけではありません。たとえば、GNOMEウィンドウ・マネージャは、ファイル・リストをURIのリストとして表現します。

   回避方法: ファイルを取得するには、String型のデータを要求したあと、RFC 2483で説明されているtext/uri-list形式に従って文字列をファイルのリストに変換します。JavaアプリケーションからGNOME/KDEデスクトップやファイル・ブラウザにファイルをドロップできるようにするには、text/uri-list形式でデータをエクスポートします。例については、RFEの回避方法に関する項を参照してください。

4. DragGestureEventまたはDragSourceのstartDrag()メソッドの1つに渡したイメージが、後続のDnD操作中に表示されない。

   解決方法: DnD操作中のマウス・カーソルの動きに合わせて、表面にイメージがレンダリングされたウィンドウを移動します。RFEの回避方法のセクションに記載されたコード例を参照してください。

5. DnDを使用して配列を移動する方法がない。

   DataFlavorクラスには、配列を処理するコンストラクタはありません。配列のMIMEタイプには、エスケープする文字が含まれます。次の例のコードでは、IllegalArgumentExceptionがスローされます。

   new DataFlavor(DataFlavor.javaJVMLocalObjectMimeType + 
   "; class=" + 
   (new String[0]).getClass().getName())
   

   解決方法: 次の例に示すように、表現クラスのパラメータの値を引用符で囲みます(引用符はエスケープします)。

   new DataFlavor(DataFlavor.javaJVMLocalObjectMimeType + 
   "; class=" + 
   "\"" + 
   (new String[0]).getClass().getName() + 
   "\"")
   

   バグ・レポートを参照してください。

6. SwingコンポーネントでAWTのDnDサポートを使用すると、問題が発生する。

   DnD操作時に奇妙なイベントが発生する、複数の項目をドラッグ・アンド・ドロップできない、InvalidDnDOperationExceptionがスローされるなど、様々な問題が発生する可能性があります。

   解決方法: SwingコンポーネントではSwingのDnDサポートを使用します。SwingのDnD実装はAWTのDnD実装に基づいていますが、SwingとAWTのDnDを混在させることはできません。Javaチュートリアルのレッスン: ドラッグ・アンド・ドロップおよびデータ転送に関する項を参照してください。

7. ターゲットに依存するようにソースの状態を変更する方法がない。

   ターゲットに依存するようにソースの状態を変更するには、ソース・コンポーネントとターゲット・コンポーネントへの参照が同じコード領域内で必要になりますが、これは現時点ではDnD APIに実装されていません。

   回避方法: 回避方法の1つは、イベントのコンテキストを判定できるようにするためのフラグを、転送可能オブジェクトに追加することです。

   1つのJava VM内でのデータ転送では、次の回避方法を提案します。

   • ターゲット・コンポーネントをDragSourceListenerとして実装します。

   • 次の例に示すように、DragGestureRecognizer.dragGestureRecognized()でターゲットをドラッグ・ソース・リスナーとして追加します。

     public void dragGestureRecognized(DragGestureEvent dge) {
                  dge.startDrag(null, new StringSelection("SomeTransferedText"));
                  dge.getDragSource().addDragSourceListener(target);             
             }
     

   • これで、DragSourceListener()のdragEnter()、dragOver()、dropActionChanged()、dragDropEnd()の各メソッド内で、ターゲットとソースを取得できます。

8. アプリケーション内でのオブジェクト転送に長い時間がかかる。

   大量データの転送や転送オブジェクトの作成にかかる時間が長すぎます。ユーザーは、データ転送が完了するまで長時間待つ必要があります。

   この高コスト処理で転送に時間がかかりすぎるのは、Transferable.getTransferData()が終了するまで待つ必要があるからです。

   解決方法: この解決方法が有効なのは、1つのJava VM内でデータを転送する場合だけです。ドラッグ操作の前に、高コストのリソースを作成または取得しておきます。たとえば、Transferable.getTransferData()の処理時間が長くなりすぎないよう、転送可能なデータの作成時にファイルのコンテンツを取得します。

AWTのスプラッシュ画面で発生する可能性がある問題と解決策。

1. 適切なMANIFEST.MFを含むJARファイルを-classpathに指定しても、スプラッシュ画面が機能しない。
   解決方法: 次の問題の解決方法を参照してください。
2. アプリケーションのいくつかのJARファイルのどれにスプラッシュ画面のイメージを含める必要があるかが明らかでない。
   解決方法: スプラッシュ画面のイメージがJARファイルから選択されるのは、-jarコマンド行オプションでJARファイルが使用された場合のみです。このJARファイルには、SplashScreen-Imageマニフェスト・オプションとイメージ・ファイルの両方を含めるようにしてください。-classpathのJARファイルのMANIFEST.MF内でスプラッシュ画面がチェックされることは決してありません。-jarを使用しない場合でも、コマンド行で-splashを使ってスプラッシュ画面のイメージを指定できます。
3. 透明度PNGを使用したスプラッシュ画面がLinuxオペレーティング・システムで機能しない。
   解決方法: これは、X11のネイティブの制限です。Linuxオペレーティング・システムでは、半透明イメージのアルファ・チャネルが50%のしきい値と比較されます。アルファ値が0.5より高いピクセルは不透明に、アルファ値が0.5より低いピクセルは完全に透明になります。

アプリケーションの一貫性をすべてのプラットフォームで確保するには、すべてのコンポーネントやコンテナで、明示的なカラー割り当て(背景と前景の両方)を使用してください。

AWTのコンテナにはサイズの制限があります。ほとんどのプラットフォームでは、この制限は32,767ピクセルです。

• コンポーネントをページ単位で表示します。
• タブを使って一度に表示されるコンポーネントの数を減らします。

特定のグラフィカル・ユーザー・インターフェイス(GUI)コンポーネントのデバッグ時に-Dsun.awt.disablegrab=trueシステム・プロパティを設定します。

-Dsun.awt.disablegrab=true

サードパーティ・ソフトウェア(特にMetacityなどのウィンドウ・マネージャ)から課される制限のため、toFront()/toBack()メソッドが予想どおりに機能せず、他のトップレベル・ウィンドウとの関係におけるウィンドウのスタック順序が変更されない可能性があります。