リリース12
E06048-01
目次
前へ
次へ
| Oracle Applications開発者ガイド リリース12 E06048-01 | 目次 | 前へ | 次へ |
Oracle Applicationsのフォームは次に示すコンテナ・オブジェクトを使用します。
モジュール
ウィンドウ（モーダル・ウィンドウおよび非モーダル・ウィンドウの標準を含む）
キャンバス（コンテンツ・キャンバスおよびスタック・キャンバスの標準を含む）
ブロック
リージョン
モジュール・プロパティでは各フォームのルック・アンド・フィールのフレームワーク全体を設定します。
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
TEMPLATEフォームでは、モジュールにMODULEプロパティ・クラスが自動的に適用されます。このクラスの設定はGUIプラットフォームごとに異なります。
警告: MODULEプロパティ・クラスによる設定値を変更しないでください。
各フォーム内で、モジュール名がファイル名と一致していることを確認します。たとえば、POXPOMPO.fmbというフォームの場合、モジュール名（Oracle Forms Developer上の表示名）はPOXPOMPOです。
このことは、オブジェクトをユーザーのフォームから参照している場合、特に重要となります。このモジュール名が正確でないと、ズームにも影響します。
このプロパティには、フォームの実行時に最初に表示するブロック名を設定します。WORLDまたはCONTROLブロックには設定しないでください。
また、CLEAR_FORM後のカーソル位置、および「アクション」->「保存して続行」操作時のデフォルトの動作も、このプロパティで制御されます。
フレーム特性やタイトル・バー・フォント、ウィンドウ・マネージャ・ボタンなど、起動中のGUIプラットフォームの適切なルック・アンド・フィールは、APPSTANDフォームからウィンドウに自動的に継承されます。この項では、モーダル・ウィンドウおよび非モーダル・ウィンドウの動作も含め、すべてのOracle Applicationsウィンドウに共通する機能について説明します。
ROOT_WINDOWは特殊なOracle Formsウィンドウで、他のウィンドウとは異なる動作をします。ツールバー、その他の標準的なOracle Applicationsオブジェクトが正常に機能する上での妨げとなるため、ROOT_WINDOWは使用しないでください。
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
非モーダル・ウィンドウ（標準ウィンドウ）では、ユーザーが他のウィンドウやツールバーおよびメニューを操作できるようになります。非モーダル・ウィンドウは、ほとんどのアプリケーション・エンティティの表示に使用されます。
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
非モーダル・ウィンドウには、すべてWINDOWプロパティを適用します。
常に、ウィンドウに関連付けられているコンテンツ・キャンバス名を入力します。
非モーダル・ウィンドウは様々なスタイルで位置設定できます。APP_CUSTOM.OPEN_ WINDOWプロシージャにウィンドウの位置設定に関するロジックをすべてコーディングし、ウィンドウを開く結果となるイベントでそのプロシージャをコールします。（イベントの例としては、ドリルダウンのレコード・インディケータを押す、組合せブロックの「開く」ボタンを押す、別のウィンドウ内の子エンティティに移動するボタンを押すなどがあります。）
フォームの起動時に最初に表示されるフォーム・ウィンドウについても、プログラムによって位置設定を行う必要があります。
非モーダル・ウィンドウにタイトルを付ける方法、およびコンテキスト情報の表示規則については、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』で説明しています。
ウィンドウ・タイトルには、表示するデータによって変わるコンテキスト情報を含むものもあります。通常は、メイン・エンティティ・ウィンドウのタイトルは一定のままで、詳細ウィンドウのタイトルがコンテキスト情報を反映して変わります。これらの詳細ウィンドウについては、APPCOREウィンドウ・タイトリング・ルーチンを使用します。また、すべてのウィンドウについて、「タイトル」プロパティを任意の基本タイトルに設定します。
ウィンドウの最大サイズは10.3インチ幅x6.25インチ高さです。最小サイズは約2インチx2インチで、その間のサイズであればどのようなサイズでも可能です。ウィンドウの項目が特に最大サイズを必要としない場合には、ウィンドウを小さくして、画面上に他のウィンドウも表示する余地を残すようにします。
ウィンドウを閉じるための動作は明示的にコーディングして、問合せ入力モード中はウィンドウは閉じない、フォームの最初のウィンドウを閉じるとフォーム全体が閉じる、およびその他の標準的な動作が確実に保たれるようにします。閉じるための動作はAPP_CUSTOM.CLOSE_WINDOWプロシージャでコーディングします。
ウィンドウを開いたときに起動させるロジックがある場合は、APP_CUSTOM.OPEN_WINDOWにそのロジックを置きます。ブロックのコーディネーションを制御し、ウィンドウの位置を設定するためのロジックを追加する必要があります。
ヒント: ウィンドウの表示は明示的に指定する必要はありません。ウィンドウ内のブロックへのGO_BLOCKによってウィンドウは自動的に開きます。
関連項目: マスター詳細関連のコーディング
一定のウィンドウでいくつかのメニュー・エントリを無効にする場合はAPP_SPECIALルーチンを使用します。「ファイル」->「保存」および「ファイル」->「保存して次を入力」メニュー・エントリの制御には、「保存」の有効化および無効化が必要です。APP_FORM.QUERY_ONLY MODEをコールすると、「保存」が自動的に無効化されます。
関連項目: APP_SPECIAL: メニューおよびツールバー・コントロール
モーダル・ウィンドウでは、ユーザーの作業範囲は単一のウィンドウ内に限定され、実行可能な操作も、行った修正を確定するか取り消すかのいずれかです。モーダル・ウィンドウにはメニューが関連付けられていますが、ユーザーはアクセスできません。旧式の画面でツールバーやメニュー（メニュー付モーダル・ウィンドウ）に限定的にアクセスできるものがありますが、新規のインスタンスを作成もコーディングもしないでください。
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
モーダル・ウィンドウはWINDOW_DIALOGプロパティを使用して作成します。WINDOW_DIALOG_WITH_MENUプロパティは下位互換性のためにあるもので、新規のウィンドウには使用しないでください。
常に、ウィンドウに関連付けられているコンテンツ・キャンバス名を入力します。
モーダル・ウィンドウは常に画面の中央に表示されます。開くたびに、中央位置に戻ります。
モーダル・ウィンドウを開くためのコードに次のコールを含めます。
app_window.set_window_position('<window_name>','CENTER');関連項目: ウィンドウが開くときの位置設定
モーダル・ウィンドウは、システム固有のGUIウィンドウ・クローズ・メカニズムで閉じることができます。また、通常は次のボタンを使用して、コードで明示的に指定することもできます。
OK - ウィンドウを閉じます。コミットを実行する場合もあります。
ヒント: 「OK」を特定の動詞で代替することも可能です。たとえば、転記前に追加情報を記録するように設計されたウィンドウでは、「OK」と「取消」とするより「転記」と「取消」としたほうがより明確となります。
取消 - 確認の問合せなしにデータが消去され、ウィンドウが閉じます。
適用 - ウィンドウでの変更は処理されますが、ウィンドウはクローズされません。
ウィンドウ・クローズ・ボックス - 「取消」ボタンと同様に機能します。
モーダル・ウィンドウを閉じるには、まずカーソルを別のウィンドウ内のブロックに移動する必要があります。
例: トリガー: 項目CANCELでのWHEN-BUTTON-PRESSED
go_block('LINES');
hide_window('APPROVE_LINES');モーダル・ウィンドウ内での特定のKEYトリガーのトラップについての情報は「ダイアログ・ブロック」を参照してください。
関連項目: ダイアログ・ブロック
この項では、コンテンツ・キャンバスおよびスタック・キャンバスの設定について説明します。
キャンバスの使用方法および動作の詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
常に、キャンバスを表示するウィンドウ名を入力します。
この項では、コンテンツ・キャンバスについて説明します。
すべてのコンテンツ・キャンバスにCANVASプロパティ・クラスを適用します。
コンテンツ・キャンバスを表示するウィンドウと同じサイズを指定する必要があります。
特定のウィンドウのコンテンツ・キャンバス前面に、1つ以上のスタック・キャンバスを表示できます。必要に応じて、1つのスタック・キャンバスをウィンドウ画面全体に表示することも可能です。
リージョンを使ったスタック・キャンバス動作の詳細は、「代替リージョン」を参照してください。
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
正しく動作させるには、スタック・キャンバスにはCANVAS_STACKEDプロパティ・クラスを使用する必要があります。
スタック・キャンバスについて、次の表示特性に従う必要があります。
ウィンドウを最初に開いた際に表示するスタック・キャンバスのみを「可視」に設定する必要があります。
スタック・キャンバスでは、「エントリでレイズ」を常に「Yes」に設定します。
（代替リージョンでのように）互いにスタックされているキャンバスは、すべて同じサイズにする必要があります。
スタック・キャンバスが適用されるリージョンでは、コンテンツ・キャンバスは空白にします。
同一ウィンドウ内に複数のスタック・キャンバスがあり、オーバーラップしている可能性がある場合、適切なキャンバス全体またはその一部が表示されるように順序を設定する必要があります。
ユーザーが参照できないスタック・キャンバスは、できるかぎり明示的に非表示として設定してください。これにより、ウィジェットを消費するリソースを減らすことができます。
この項では、すべてのブロックの一般設定とともに、次のような状況におけるブロックのセットアップ方法を説明します。
コンテキスト・ブロック
ダイアログ・ブロック
実表のないデータ・ブロック
マルチ・レコード・ブロック
シングル・レコード・ブロック
組合せブロック
マスター詳細関連
動的WHERE句
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
ブロックの一般的な設定を次に示します。
すべての非モーダル・ブロックにBLOCKプロパティ・クラスを使用します。また、モーダル・ウィンドウ内に表示されるブロックにはBLOCK_DIALOGを使用します。
このクラスの視覚属性グループ・プロパティは絶対に上書きしないでください。このプロパティはプラットフォームごとに異なります。
ブロックが表または単一の表ビューに基づいている場合には、キー・モードを「一意」に設定します。ブロックが結合ビューに基づいている場合には、更新許可をNoに設定します。少なくともブロック内の1項目を主キーとして必ずマークします（データ・ブロックの主キーを構成する各項目について、項目レベルで主キーを設定）。
ブロックを削除できないようにするには、ブロックの「削除可」を「No」に設定します。（削除を不可にする目的のためにDELRECトリガーを使用しないでください。）
ナビゲート可能なすべてのブロックについて、この2つのプロパティを設定します。これらの設定は次のブロックおよび前のブロックへのナビゲーション順序に影響します。CONTROLまたはWORLDには設定しないでください。
最初のブロックでは「前のナビゲーション・データ・ブロック」をそのブロック自身に設定し、最後のブロックでは「次のナビゲーション・データ・ブロック」をそのブロック自身に設定します。
「次のナビゲーション・データ・ブロック」を実行時に動的に変更する場合でも、このプロパティを論理的に適切な、なんらかの設定をする必要があります。最も合理的な次および前ブロックのフローを選択してください。
コンテキスト・ブロックは詳細ウィンドウに表示され、コンテキストを示します。このブロックは、マスター・ウィンドウに表示されるフィールドを複製します。コンテキスト・ブロックを作成するには、マスターと同じブロック内にある表示項目を作成して、マスター・フィールドとコンテキスト・フィールドを同期させます。
ダイアログ・ブロックはモーダル・ウィンドウ内に表示されるブロックです。このブロックが使用されている場合、ユーザーはアプリケーション内の他のウィンドウに進む前にこのブロックとのやり取りを要求されます。
関連項目: モーダル・ウィンドウ
「保存」、「次のブロック」、「すべて消去」など、ほとんどの標準Oracle Formsファンクションは、ダイアログ・ブロックでは適用されません。Oracle ApplicationsのメニューおよびツールバーからOracle Formsファンクションにアクセスできない場合でも、ユーザーが無効に設定していないかぎりキーボードからはそれらを呼び出すことができます。APP_EXCEPTION.DISABLEDをコールするKEY-OTHERSトリガーをコーディングして、ブロックのすべてのKEYトリガーを無効にする必要があります。こうしておくと、無効なファンクションを試行した場合に警告音が鳴ります。その後で、次の表にリストされているKEYトリガーをコーディングして、ブロックの特定のファンクションを有効にします。
| KEY-トリガー | コード |
|---|---|
| KEY-OTHERS | app_exception.disabled; (1) |
| KEY-NEXT-ITEM | next_item; |
| KEY-PREVIOUS-ITEM | previous_item; |
| KEY-CLRREC | clear_record |
| KEY-EDIT | app_standard.event('KEY-EDIT'); |
| KEY-LISTVAL | app_standard.event('KEY-LISTVAL'); |
| KEY-ENTER | enter; |
| KEY-HELP | app_standard.event('KEY-HELP'); |
| KEY-PRINT | print; |
(1) このコードにより、ブロック内の、特にKEY-トリガーがコーディングされていないすべてのKEY-ファンクションが無効化されます。
ダイアログ・ブロックにより複数のレコードが許可されている場合は、次の表にリストされているKEY-トリガーも有効化する必要があります。
| KEY-トリガー | コード |
|---|---|
| KEY-CREREC | create_record; |
| KEY-NXTREC | next_record; |
| KEY-PREVREC | previous_record; |
| KEY-UP | up; |
| KEY-DOWN | down; |
個々のダイアログ・ブロックの必要性に応じて、その他のファンクションも有効化できます。
ほとんどのファンクションが有効にされる場合、無効にする特定のファンクションについてKEYトリガー内でAPP_EXCEPTION.DISABLEDをコールすることにより、それらの適用しないファンクションのみを無効にします。
モーダル・ウィンドウが開いている間は、ダイアログ・ブロックの外の項目へのナビゲーションは回避する必要があります。[Tab]キーでの移動をウィンドウ内のフィールドに制限する必要があります。次のガイドラインに従って、ダイアログ・ブロックの外へのナビゲーションを回避します。
通常、ブロックのナビゲーション・スタイルは「同一レコード」です。「データ・ブロックの変更」には絶対にしないでください。
「次のナビゲーション・データ・ブロック」と「前のナビゲーション・データ・ブロック」は、そのデータ・ブロック自身と同じにする必要があります。
ユーザーの移動がダイアログ・ブロック内に限定されるように、「次ナビゲーション項目」プロパティと「前ナビゲーション項目」プロパティを設定します。
実表またはビューのないブロックを実装する必要がある場合があります。そのようなブロックでコミット処理を行う必要がある場合は、トランザクション・トリガー（ON-INSERT、ON-LOCKなど）を使用します。
ブロックをFND_DUALのようなダミー表に基礎付けないでください。
たとえば、「在庫品目の移動」フォームでは、画面に入力されたデータを処理するためコンカレント要求を送信します。そのため、コンカレント処理発行ルーチンを呼び出すためのON-INSERTトリガーをコーディングします。
関連項目: コンカレント処理
シングル・レコード・データ・ブロックでは、1度に1つのレコードを参照するかわりに、1つのエントリについて可能なかぎり多くの項目を参照できます。
ブロックに詳細ブロックがない場合、または詳細ブロックが別のウィンドウ内にあるという場合は、ナビゲーション・スタイルを「同一レコード」に設定する必要があります。それ以外は「データ・ブロックの変更」に設定します。
データのレコードが1つしかないデータ・ブロックについては、「実行」メニューで、最初のレコード、最後のレコード、次のレコード、前のレコードの各オプションを無効化することもできます。
これを行うには、次のとおりの行でブロック・レベルのWHEN-NEW-RECORD-INSTANCEトリガー（実行階層: オーバーライド）をコーディングします。
app_standard.event('WHEN-NEW-RECORD-INSTANCE');
app_special.enable('SINGLE', PROPERTY_OFF);
キーを使用してシングル・レコード・ブロックと相容れないファンクションを実行しないようにするには、ブロック・レベルのKEY-DOWNトリガー、KEY-CRERECトリガーおよびKEY-NXTRECトリガー（実行階層: オーバーライド）を次のとおり含めてコーディングします。
app_exception.disabled;
関連項目: APP_SPECIAL: メニューおよびツールバー・コントロール
マルチ・レコード・ブロックでは、1つのエントリについて可能なかぎり多くの項目を表示させることができます。通常、そのかわりに、同時に表示できる各レコードの属性数が減少します。
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
ブロックがドリルダウンをサポートしているかどうかによって、各マルチ・レコード・ブロックに対し現在のレコードのインディケータまたはドリルダウン・インディケータのいずれかを指定する必要があります。
すべてのマルチ・レコード・ブロックについてナビゲーション・スタイルを「レコード変更」に設定します。
ブロックに詳細ブロックがなく、したがってドリルダウンがサポートされていない場合は、次の手順に従って現在のレコードのインディケータを作成します。マルチ・レコード・ブロックにテキスト項目を作成します。テキスト項目の名前をCURRENT_RECORD_INDICATORにして、プロパティ・クラスにCURRENT_RECORD_INDICATORを指定します。
インディケータ上でシングルクリックすると、適切なレコードの最初のナビゲート・フィールドにカーソルが移動します。レコード・インディケータ項目に項目レベルのWHEN-NEW-ITEM-INSTANCEトリガー（実行階層: オーバーライド）を作成することでこれが実行され、ブロックの最初のフィールドにGO_ITEMが渡されます。たとえば、次のようにします。
GO_ITEM('lines.order_line_num');
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
マルチ・レコード・ブロックで1つ以上の詳細ブロックへのドリルダウンがサポートされている場合には、次の手順に従ってドリルダウン・インディケータを作成します。マルチ・レコード・ブロックにテキスト項目を作成します。テキスト項目の名前をDRILLDOWN_RECORD_INDICATORにして、プロパティ・クラスにDRILLDOWN_RECORD_INDICATORを指定します。
ドリルダウン・インディケータ項目に、項目レベルのWHEN-NEW-ITEM-INSTANCEトリガー（実行階層: オーバーライド）を追加します。ドリルダウン・ブロックに対応するボタンと同じロジックをコールします。組合せブロックでは、これによって「詳細」ウィンドウへと移動します。その他のブロックでは、子ブロックが1つ以上ある場合、ドリルダウンによってそれらのうちの1つに移動します。
ドリルダウン・ブロックへの移動が許可されておらず、対応するボタンが使用できないという可能性を考慮に入れる必要があります。ドリルダウンを実行する前に、WHEN-NEW-ITEM-INSTANCEトリガーにこのような状況が発生していないかを確認してください。ドリルダウンが有効でない場合には、APP_EXCEPTION.DISABLEDにコールを発行して、現在のブロックの最初の項目へ移動します。
詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
組合せブロックはハイブリッド書式のブロックで、フィールドはマルチ・レコード（要約）書式およびシングル・レコード（詳細）書式で表示されます。要約書式と詳細書式はそれぞれ別個のウィンドウに表示されますが、両方の書式ともフィールドはすべてシングル・ブロックの一部となります。
重要: 「要約 - 詳細」の詳細と「マスター - 詳細」の詳細を混同しないように注意してください。
「詳細」ウィンドウのボタンは、「要約」ウィンドウから利用できない付加的操作を含んでいる可能性があります。
関連項目: 『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』
マスター詳細関連のルック・アンド・フィールの詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
関連項目: マスター詳細関連のコーディング
詳細レコードは、マスター・レコードのコンテキストにおいてのみ、入力および問合せが可能です。「データ整合」プロパティは常に「マスターなし操作防止」に設定します。
フォームは、実際の表ではなく基礎となるビューを使用して構築する必要があるため、詳細レコードについては通常のOracle Forms削除を使用しないようにする必要があります。そのかわり、関連の「マスター削除」プロパティを「孤立」に設定し、その後、マスター表の表ハンドラでDelete_Rowプロシージャの一部として詳細レコードを削除します。
詳細ブロックがマスターではない別のウィンドウにあり、その詳細ウィンドウがモーダルである場合、その詳細ブロックはブロックへのナビゲーションに基づいてのみ問合せを行います。関連の「データ整合」を「遅延」および「自動問合せ」に設定します。この関連に対し、OPEN_WINDOWまたはCLOSE_WINDOWプロシージャでどのようなロジックのコーディングも行わないでください。
次の場合以外、フォームの最初のマスター・ブロックでは自動問合せは行われません。
極少数のレコードのみが返される場合
問合せが迅速な場合
最も一般的な場合として、ユーザーが問合せを行ったレコードを1つ以上操作する場合
フォームの最初のブロックを自動問合せするには、次のようにコーディングします。
Trigger: WHEN-NEW-FORM-INSTANCE
do_key('execute_query');
マスター・ブロックを含むウィンドウをアイコン化することで詳細ブロックの操作が難しくなる場合でも、アイコン化されたウィンドウに特有のコーディングを行わないでください。
クライアント・サイドでの操作効率が悪いため、マスター詳細のカスケード削除は使用しないでください。カスケード削除では、ハードコードされたメッセージを持つトリガーも生成されます。
次のような場合、実行時にブロックのデフォルトのWHERE句を修正できます。
ブロック内の問合せ実行が、常に新規条件に基づく必要がある場合。
ユーザーによって要求された問合せ行で、他のSQLによる複雑なサブ選択を必要とする場合。
上記以外の場合はすべて、PRE-QUERYトリガーの値が単に移入されます。
リージョンはフィールドのグループです。ほとんどのリージョンは単に表面的な見え方のためのもので、関連フィールドのグループがフレーム（ボックス）で囲まれていたり、関連フィールドのグループの上方にフレーム（線）が表示されたります。これらの場合には、カーソルがリージョン内に入ると、ブロック・タブ移動の順序がリージョン内のすべての項目を移動してからブロック内の他のリージョンやフィールドに移動するようにする以外は、コード上の影響はありません。
タブ・リージョンと呼ばれる一定のリージョンは、選択時にのみ、タブ・キャンバス上に表示されます。
関連項目: タブ・リージョンのコーディング
オーバーフロー・リージョンでは、マルチ・レコード・フィールド直下のシングル・レコード書式内に、マルチ・レコード・ブロックの追加フィールドが表示されます。
関連するブロック内にこれらのフィールドを作成して、「表示項目数」プロパティを1に設定します。
