フォームアプリケーション教書　第１部　ランチャー 　 WEBサイト 桐の釣魚大全 より転載

　　　　　＊ランチャーが試せるツールが公開されています。
　　　　　　WEBサイト 桐の釣魚大全 →ワークショップへ → ダウンロード → テストツール→ INF_Guide_Launcher

　■ランチャーに関する雑談 ― ブログ版　桐のイベント道場　2007/3/17 INF_Toolsの話　第２９話より
　※執筆当時の INF_Tools は INF_Framework に置き換えました。

　　ランチャーというのは案外と面倒なものです。
　INF_Framework のランチャーは次の順で動作します。

　　まず、すでにそのファイルのウィンドウが在るか否か調べて
　　　↓
　　次に、ウィンドウでなく編集表と開いている表が在るか否か調べて、
　　　↓
　　次に、ディスクに目標のファイルが存在するか否か調べて、
　　　↓
　　最後に、本当にフォームや表を開きます。

　　なお、すでにファイルのウィンドウがある場合は、そのウィンドウへフォーカスし、
　　すでにウィンドウでなく編集表として開いている表がある場合は、メッセージボックスで通知します。

　　また、すでに開いたウィンドウのハンドルを覚えている方式は具合悪いので、ランチャーは以上の作業をその都度行います。
　つまり、常に最新のウィンドウハンドルを精査することがランチャーの重要な点です。
　いうなれば、常にリアルタイムな情報を収集することがランチャーの基本設計になります。

　　ランチャーの機能は、ミサイルに例えるのが適当です。ミサイルには、無誘導式・誘導式・打ちっ放し式があります。
　　○無誘導式　　 ― コマンドボタンの［機能名：開く］です。
　　○誘導式　　　 ― すでに開いたウィンドウのハンドルを覚えている方式ですが、ハンドル情報が実際と食い違うトラブルが発生します。
　　○打ちっ放し式 ― INF_Framework が採用しているリアルタイムな情報を収集する方式です。

　　実際の打ちっ放し式のミサイルには、シーカー（探知機）があります。
　これは、ランチャー機能の
　　まず、すでにそのファイルのウィンドウが在るか否か調べて
　　　↓
　　次に、ウィンドウでなく編集表と開いている表が在るか否か調べて、
　に相当します。
　　つまり、目標のウィンドウや、編集表が在るか否か調べる機能です。
　そして、もしも、目標のウィンドウや、編集表が無ければ、ディスクに目標のファイルが存在するか調査して、ランチャーはフォームや表を本当に開くというわけです。

　INF_Framework のランチャーに関するメモ　1st_Spec_Memo_HDLLNC.txt INF_Framework 第3.3版 改訂版(MkII) より転載

　■引数について

　ランチャーの基本形は次の通り。

　手続き実行　HDLLNCprcWindowAppear( &wfm, &tbl, &hdl, &openStatus )

　引数の意味は変数名から容易に想像できると思います。

　すなわち、

　・&wfm　　　　 …　フォームファイル名　※フルパスで指定

　・&tbl　　　　 …　表ファイル名　　　　※フルパスで指定

　・&hdl 　…　&hdl には成功時にハンドル番号が、失敗時にはゼロ(０)が代入されます

　・&openStatus　…　&openStatus には、新規にウィンドウを開いた時にイチ(１)、それ以外にはゼロ(０)が代入されます

　引数の &hdl, &openStatus は単なる戻り値なので分かりやすいのですが、

　&wfm と &tbl の両方を指定した場合はどうなるのだろうか？という疑問が生じることでしょう。

　&wfm と &tbl の組み合わせは、以下のように４通りになります。

　　　　&wfm　&tbl　　○：ファイル名あり　×：未定義値
　　1.　○　　×
　　2.　○　　○
　　3.　×　　○
　　4.　×　　×

　この組み合わせに対するランチャーの挙動は以下のようになります。

　　　　&wfm　&tbl　挙動
　　1.　○　　×　　フォームをローンチ（ランチ）
　　2.　○　　○　　フォームをローンチ（ランチ）
　　3.　×　　○　　表をローンチ（ランチ）
　　4.　×　　×　　無効なのでヘルプを表示する

　この組み合わせの中で判り難いと思われものは 2.の組み合わせですが、

　　　　&wfm　&tbl　挙動
　　2.　○　　○　　フォームをローンチ（ランチ）

　フォーム:&wfmと、表:&tblの両方を指定した場合には、ランチャーはフォームをローンチ（ランチ）します。

　実は、この場合の表:&tblはフォームの編集対象表の指定になります。

　■フォームの編集対象表の指定ついて

　編集対象表を伴っているフォームをローンチ（ランチ）する場合、

　時として編集対象表の表がすでに開いていることがあります。

　その場合には、桐からエラーメッセージ［KU0192　○○.tbl　表 はすでに使用されています］が表示されます。

　この時に、表:&tblにフォームの編集対象表を指定しておくと、桐に代ってランチャーが次のどちらかのメッセージを表示します。

　　【phase1A　表のウィンドウが存在する場合】
　　ターゲットのフォームの編集対象表とする表がすでに開いています
　　　　：
　　ターゲットのフォームは開かれませんでした

　　【phase2C　表のウィンドウが存在しない場合】
　　ターゲットのフォームを開く以前に
　　編集対象表とする表がイベント処理で使用されています
　　　　：
　　ターゲットのフォームは開かれませんでした

　おそらくランチャーのメッセージの方が、［KU0192　○○.tbl　表 はすでに使用されています］よりも意味が理解しやすいことでしょう。

　なお、表のウィンドウが存在する場合には、ランチャーは自動的に表のウィンドウをフォーカスします。

　以上の理由から、編集対象表を伴うフォーム:&wfmを指定する場合には、表:&tblにフォームの編集対象表名を指定することを推奨します。

　■オプション（検索対象から除外する）

　↑前の説明のように、フォーム:&wfmと表:&tblの両方を指定した場合には、フォームの編集対象表名も検索対象になります。

　しかし、フォームの編集対象表名を検索対象にしたくない場合もあります。

　それは、［フォームの属性］→［許可作業］→［多重化］が ON の場合です。

　フォームの編集対象表の多重化が許可されている場合には、※もちろん、表:&tblを未定義値にすればＯＫなのですが…(^^ゞ

　次のようにすれば、表:&tblにファイル名を指定したままで検索対象から除外出来ます。

　（例）
　名札　メイン
　　：
　変数宣言　局所，整数｛ &LNCmExact ｝ /* ON:1 OFF:0 または未定義値 */
　　：
　＊

┌手続き定義開始　prcProcedureName( )
│
│　　：
│　&LNCmExact = 1　/* 表:&tblを検索対象から除外します */
│　手続き実行　HDLLNCprcWindowAppear( &wfm, &tbl, &hdl, &openStatus )
│　　：
│
└手続き定義終了

　■［コマンドボタンの機能名：開く］と［ランチャー］の違い

　＜NULLフォームを開く場合＞

　NULLフォームをコマンドボタンで開くと、コマンドボタンを実行する度に新規にフォームが開いていきます。

　この時、NULLフォームが複数開かれていてもウィンドウが重なって表示されるために気が付かないことが多いです。

　しかし、ランチャーでNULLフォームを開くと、NULLフォームが複数開かれることはありません。

　NULLフォームがすでに開いていた場合には、ウィンドウをフォーカスするだけです。

　＜オーバーラップ形式のフォームの場合＞

　オーバーラップ形式のフォームでコマンドボタンで表を開くと表ウィンドウが開かれますが、

　その表ウィンドウはオーバーラップ形式のフォームに隠されて見えません。

　一方、ランチャーで表ウィンドウを開こうとすると、

　次のメッセージが表示されて表ウィンドウはローンチ（ランチ）されません。

　　【phase3B　表のウィンドウが存在しない場合】
　　オーバーラップ形式のフォームなので表ウィンドウは表示できません。
　　　　：

　　【phase2A　表のウィンドウが存在する場合】
　　表がすでに開いています
　　　　：
　　オーバーラップ形式のフォームなので
　　表編集ウィンドウをフォーカスできません

　以上