10.9 その他の問題

10.9.1 スプラッシュ画面の問題

このセクションでは、AWTのスプラッシュ画面で発生する可能性のあるいくつかの問題を説明します。

• 問題1 - 適切なMANIFEST.MFを含むJARファイルを-classpathに指定しても、スプラッシュ画面が機能しない。

  解決方法: 次の問題の解決方法を参照してください。

• 問題2 - アプリケーションのいくつかのJARファイルのどれにスプラッシュ画面のイメージを含めるべきかが明らかでない。

  解決方法: スプラッシュ画面のイメージがJARファイルから選択されるのは、-jarコマンド行オプションでJARファイルが使用された場合のみです。このJARファイルには、「SplashScreen-Image」マニフェスト・オプションとイメージ・ファイルの両方を含めるようにしてください。-classpathのJARファイルのMANIFEST.MF内でスプラッシュ画面がチェックされることは決してありません。-jarを使用しない場合でも、コマンド行で-splashを使ってスプラッシュ画面のイメージを指定できます。

• 問題3 - 透明度PNGを使用したスプラッシュ画面がOracle SolarisやLinuxオペレーティング・システムで機能しない。

  解決方法: これは、X11のネイティブの制限です。Oracle SolarisおよびLinuxオペレーティング・システムでは、半透明イメージのアルファ・チャネルが50%のしきい値と比較されます。アルファ値が0.5より高いピクセルは不透明に、アルファが0.5より低いピクセルは完全に透明になります。半透明のサポートは、Java SEの将来のバージョンで改善される可能性があります。

10.9.2 トレイ・アイコンの問題

Windows 98のJava SE 6リリースではTrayIcon.displayMessage()メソッドがサポートされていませんが、これは、バルーン表示用のネイティブ・サービスがWindows 98でサポートされていないからです。

SecurityManagerがインストールされている場合、TrayIconオブジェクトを作成するには、AWTPermissionの値がaccessSystemTrayに設定される必要があります。

10.9.3 ポップアップ・メニューの問題

JPopupMenu.setInvoker()メソッドで、呼出し元(invoker)とは、ポップアップ・メニューの表示先となるコンポーネントのことです。このプロパティがnullに設定されていると、ポップアップ・メニューが正しく機能しません。

解決方法は、ポップアップの呼出し元を自分自身に設定することです。

10.9.4 背景色と前景色の継承

多くのAWTコンポーネントでは、背景色や前景色として、親のカラーではなく独自のデフォルトが使用されます。

この動作はプラットフォームに依存しています。つまり、プラットフォームが異なれば、同じコンポーネントでも違った動作になることがあります。また、コンポーネントの中には背景色または前景色のどちらか一方にはデフォルト値を使用するが、もう一方の色については親の値を取るものもあります。

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

10.9.5 AWTパネルのサイズ制限

AWTのコンテナにはサイズの制限があります。ほとんどのプラットフォームでは、この制限は32767ピクセルです。したがって、たとえばキャンバス・オブジェクトの高さが25ピクセルであれば、Java AWTパネル上に1310個を超える数のオブジェクトを表示することはできません。

残念ながら、この制限を変更する方法はなく、Javaコードやネイティブ・コードを使っても変更できません。この制限は、オペレーティング・システムでウィジェット・サイズの格納に使用されるデータの型に依存します。たとえば、Windows 2000/XPオペレーティング・システムやLinuxオペレーティング・システムではinteger型が使用されるため、整数の最大サイズが制限値となります。ほかのオペレーティング・システムでは、longなど別の型が使用されている可能性があり、この場合であれば制限は高くなります。

詳細は、使用しているプラットフォームのドキュメントを参照してください。

役立つ可能性のあるこの制限の回避方法の例を次に示します。

• コンポーネントをページ単位で表示します。

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

10.9.6 X11上でポップアップ・メニューや類似コンポーネントのデバッグ中にハングアップする

特定のグラフィカル・ユーザー・インタフェース(GUI)のアクションでは、そのアクションを終了させるタイミングを決めるために、すべての入力イベントをグラブする必要があります(ポップアップ・メニューの移動など)。占有が続いている間は、ほかのアプリケーションは入力イベントを一切受け取りません。Javaアプリケーションのデバッグ時に、グラブがアクティブになっている間にブレークポイントに達すると、オペレーティング・システムがハングアップしたようになります。これは、グラブを保持しているJavaアプリケーションがデバッガによって停止され、入力イベントを一切処理できなくなったために起こります。他のアプリケーションは、このインストールされたグラブのせいでイベントを受け取らないだけです。そのようなアプリケーションのデバッグを可能にするには、デバッガからアプリケーションを実行する際に次のシステム・プロパティを設定するようにしてください。

-Dsun.awt.disablegrab=true

これにより事実上、グラブの設定がオフになるので、システムがハングアップしなくなります。ただし、このオプションが設定されていると、場合によっては、通常であれば終了するはずのGUIアクションが終了できなくなります。たとえば、ウィンドウのタイトル・バーをクリックしてもポップアップ・メニューが終了しない可能性があります。

10.9.7 X11でのWindow.toFront()/toBack()の動作

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

アプリケーションで最終的にウィンドウが手前に表示されるようにする場合は、まずWindow.setAlwaysOnTop(true)を呼び出して一時的にウィンドウが常に手前に表示されるようにしてから、setAlwaysOnTop(false)を呼び出して「常に手前に表示」の状態をリセットすることで、この問題の回避を試みることができます。