すべての画面には到着ファンクションが含まれています。
通常、画面の到着スクリプトは1 つのデフォルト動作を定義します。
代表的な 1 つデフォルト動作は以下のとおりです。
ただし、ジャンクション、スペシャル、またはデスティネーション画面を変更して、複数の異なる動作をサポートしなければならない場合も時にはあります。
これを実行する最も構造的な方法としては、最初に到着スクリプトでサポートする動作を決定することです。次に、以下の例のように画面スクリプトの開始時にこれらの動作を明確に定義し、ドキュメント化します。
RequestedArrivalBehaviour : 0,
ArrivalBehaviours :
{
Default : 0, /* Default behaviour */
SearchNext : 1, /* Handle scroll up request */
SearchLast : 2, /* Handle scroll down request */
ForcedNavigation : 3, /* Handle a forced navigation */
AutoConfirmation : 4 /* Handle auto confirnmation */
},
ここでは、この画面が 5 つの異なる到着動作をサポートできることを正式に定義しています。
注1: この方法で動作を定義する必要はなくなく、異なる名前を使用することができます。これは正式にこれを行う方法の例です。この方法は、ドキュメント化とデバッグで利点があります。このセクションの最後に、より簡素な方法に関する注記がありますので、参照してください。
注2: これらの動作と名前は架空のものです。任意の名前を使用して必要な数の動作を使用することができます。
次に、画面の到着スクリプトを実際に変更し、これらの複数の動作を処理する必要があります。以下のデスティネーション画面のサンプル到着スクリプトのように、これも構造化された方法で実現できます。
vHandle_ARRIVE: function(oPayload, oPreviousForm)
{
/* Extract a copy of the requested behaviour */
var RequestedBehaviour = this.RequestedArrivalBehaviour;
/* Reset the requested behaviour back to the default behaviour */
this.RequestedArrivalBehaviour = this.ArrivalBehaviours.Default;
/* Now preform the requested behaviour */
switch (RequestedBehaviour)
{
case this.ArrivalBehaviours.Default:
SHOW_CURRENT_FORM(true);
HIDE_5250_BUTTONS();
SETBUSY(false);
break;
case this.ArrivalBehaviours.SearchNext:
/* Logic to handle search next page behaviour*/
break;
case this.ArrivalBehaviours.SearchLast:
/* Logic to handle search last page behaviour*/
break;
case this.ArrivalBehaviours.ForcedNavigation:
/* Logic to handle a forced navigation, whatever that may be */
break;
case this.ArrivalBehaviours.AutoConfirmation:
/* Logic to handle a an auto confirmation, whatever that may be */
break;
default:
ALERT_MESSAGE(this.vName,"arrival script – invalid behaviour requested",RequestedBehaviour.toString());
}
/* <ARRIVE /> - Do not remove or alter this line */
return(true);
},
これで、画面がサポートする異なる到着動作、およびそれらを実装するために必要なコードが正式に定義されました。
この使用方法は次の通りです。
まず、ペイロードを使用する代わりに、画面独自のスクリプト内でこれを使用します。
以下のようなページ検索操作を要求するボタン・クリックを考えてみましょう。
SENDKEY(KeyPageUp,"SEARCHNEXT");
従来、これはキー・ストロークをサーバーに送信し、ペイロードを含んでいました。このため、到着スクリプトはフォームが再び戻ってきたときに実行する内容を認識できます。
注: これを実行した場合、少なくとも2つの動作を提供する到着スクリプトがすでにあった可能性があります。
代わりに、以下のようにコード化します。
this.RequestedArrivalBehaviour = this.ArrivalBehaviours.SearchNext;
SENDKEY(KeyPageUp);
注：なぜこのようにするのでしょうか? 手間がかかるように感じます。ここで、すでに1つの利点を得ています。ペイロード・テクニックを使用して、誤ってSENDKEY(KeyPageUp,"SEARCHNET")とコード化したとします。プログラムをデバッグし、"SEARCHNET"が間違っていて"SEARCHNEXT"にする必要があることがわかるまでしばらく時間がかかります。ArrivalBehaviours.SeachNetをコード化した場合、それを実行するとスクリプトが失敗し、何か問題があることが即座に通知されます。
これを使用する2番目の場所はその他の画面です。
例えば、別の画面("AnotherScreen")が複数動作の画面("MultiScreen")に最終的に到着するまたはその画面を通過することがわかっている一連のイベントを発生させようとしています。
また、この画面は"MultiScreen"が到着時に「自動確認」を実行することを確認する必要もあるとします。
"AnotherScreen"には、以下のコードを含めることができます。
var oMS = SCREEN("MultiScreen"); /* Get a reference to "MultiScreen" */
oMS.RequestedArrivalBehaviour = oMS.ArrivalBehaviours.AutoConfirmation;
<< Now execute code to start events that will go to/though "MultiScreen" >>
つまり、"AnotherScreen"は、「到着したときに通常のデフォルトの動作ではなく自動確認動作を実行する」という、"MultiScreen"(RequestedArrivalBehaviour)のプロパティを設定しています。
"MultiScreen"はデスティネーション画面である必要はありません。これは、スペシャル画面のジャンクションと同等であると考えられます。必要なのは、これが異なる動作を実行できる必要がある到着スクリプトを含む画面であるということです。
このテクニックは、画面がその間で意図を通信するための非常に正式かつ構造化された方法を示しています。正式すぎたり、構造化すぎる必要はなく、提案されている長い名前を使用する必要もありません。
以下のように、"MultiScreen"で簡潔に宣言できます。
Action : 0, /* Declare the action code for arriving scripts */
次に、以下のように到着スクリプトを構造化します。
Switch (Action)
Case : 0
Case : 1
Case : 2
Case : 3
他のコードは、this.Action = 2またはSCREEN("MultiScreen").Action = 3を使用します。
また、以下のように文字列を使用することもできます。
Action : "Default", /* Declare the action code for arriving scripts */
次に、以下のように到着スクリプトを構造化します。
Switch (Action)
Case : "Default"
Case : "Up"
Case : "Down"
Case : "Jump"
他のコードは、this.Action = "Up"またはSCREEN("MultiScreen").Action = "Jump"を使用します。
使用した宣言のテクニックは取るに足りません。また、長くなっています。これは、構造化され、ドキュメント化されています。正式な宣言 (列挙型) テクニックの利点は、単にこれが機能の正式なドキュメントであること、および不適切な値を使用した場合、常にコードが失敗することです。
