久しぶりのWideStudioネタです。最近、また触り始めました。現行のSIPHA SYSTEM端末ソフト、かなりベタベタな感じになってしまっているので、メンテナンス性の向上を目指して作り直そうと考えています。今後、いくつかのタイプのCOREを作ろうと思っていまして、対応しやすいようにしたいなって思ってます。

で、プログラムのメンテナンス性の悪いと感じる一因として、WideStudioでプログラムを作ると、どうもソースファイルの数が増えてしまい、エクスプローラとかで見たときに一覧性が悪くなるなぁってのがあります。で、どうしてソースファイルが増えてしまうかというと…

イベントプロシージャ用起動関数毎にソースファイルができる。

…のが原因かなって思っています。例えばSIPHA TERMの場合だと、.cppファイル（C++のソースファイル）が４３本ありますが、そのうちイベントプロシージャ起動関数を記述しているソースファイルは、なんと３３本もあります。しかも、それぞれは短めでシンプルなソースコードが書いてあるだけ。これでも、同じウィンドウにぶら下がっているボタンのような部品については、同一トリガによって呼び出されるイベントプロシージャを共有するようにしてあります。

しかし、トリガが異なる場合、どうしても異なる起動関数となり、結果としてソースファイル数が増えてしまいます。でも、気持ちからいくと、同じウィンドウから発生するトリガぐらいは、１つのソースファイルでいいんじゃないかな？って思います。

というわけで、複数のトリガ処理を１つのソースファイルにまとめれないか、調査してみました。

同一トリガを１つの起動関数でまとめる方法
複数イベントプロシージャ処理の同一トリガを１つの起動関数でまとめるには、各オブジェクトに識別子をつけておき、それを起動関数の中で読み取って処理を振り分けることで行うことができます。具体的には、ボタンなどの部品に番号を「ユーザ設定値（WSNuserValue）」に設定しておきます。で、ボタン押下などによってイベントが発生して起動関数が呼ばれると、一緒に、WSCbaseクラスのポインタが渡されますので、このポインタを使ってgetProperty( WSNuserValue )を実行し、識別子を読み出してやります。あとは、switch文などで振り分けてやることにより、起動関数を共有化することができます。

異なるトリガを１つの起動関数でまとめるための試行錯誤
これが今回の本題です。例えば、メインウィンドウが初期化された時に変数を初期化、終了する時に確認メッセージボックスを表示させようと思ったら、これだけでソースファイルが２つになってしまいます。しかも中身はとても単純、かつ短いプログラムが書いてあるだけです。いくつかの方法を試してみて失敗したので紹介します。

1. イベントプロシージャ生成時に起動関数と異なるファイル名を選択
   あらかじめ作っておいた、まとめる目的のソースファイルを選択してみたのですが、実際に作ってみると、起動関数名がファイル名と強制的に同じになってしまってしまいました。そんなわけでボツ。どうも、WideStudioでは、ファイル名＝起動関数名となるようになっているようです。


2. 無理やり「.wns」ファイル内の定義を変更
   イベントプロシージャのファイル情報は、「～.wns」ファイルの中に入っているようです。そんなわけで、WideStudioを実行していない状態でテキストエディタで編集してみました。しかし、WideStudioを起動してプロシージャを確認したら、起動関数名がやはりファイル名と同じになってしまいました。これまたボツ。


3. イベントプロシージャを動的に生成
   イベントプロシージャというのは、WideStudio上から作る以外に、プログラム内で生成してオブジェクトに結合することができます。かのTSC16のスライダを作るところでもやっている方法です。でもこれって、あまりやりすぎると、せっかくの統合環境の意味がなくなってしまう気がするので、ボツとしました。

同一トリガを１つの起動関数でまとめる方法
最終手段で、共用として同じ起動関数を呼び出し、その中で、オブジェクトの認識やトリガの識別をすることで処理を振り分けられないか？というアイデアで行くことにします。処理が増える分、関数実行のオーバーヘッドが増えますが、それほど気にしなくても大丈夫でしょう。で、調べ始めたところ、すぐに壁にぶつかりました。それは…

起動関数内でトリガの種類が取れない！

ということです。とほほ。トリガを取得する関数はWSCprocedureクラスに実装されているのですが、これと同機能のものはWSBbaseクラスのクラスリファレンスを調べても出てきません。そんなわけで、イベントプロシージャ関数に渡されるWSCbaseクラスから取り出す方法はなさそう。しかし、WSCbaseクラスっていうのはイベントプロシージャ機能を持っているはずですから、きっとクラス内にWSCprocedureか、等価な機能が実装されているはず！というわけで、こんなときはWideStudioのインクルードファイルを漁るに限ります。きっと、WSCbaseクラスに何か隠れているんだろうと踏んで、WSCbase.h内を探してみました。

それっぽいのが出ました！

やはりWSCprocedureクラスは実装されていました。しかし、どう扱ったものかと悩みながらさらに漁っていると…PUBLIC宣言されているそれっぽいメンバ関数を発見。

WSDLEX32 WSCprocedure* getExecutedProcedure()

きっと「取得－実行された－プロシージャー」という名前からして、自WSCbaseクラスで実行されたプロシージャクラス情報を取得できるんでしょう。というわけで、さっそくプログラムを書いて試してみました。要点だけ書くと、以下のようなものです。

WSCprocedure* wprocPtr = object->getExecutedProcedure();
switch( wprocPtr->getTrigger()){
case WSEV_INITIALIZE:
    //  INITIALIZEトリガ時の処理
    break;
case WSEV_EXIT:
    //  EXITリガ時の処理
    break;
default:;
}

よかったよかった。思ったとおりです。とはいっても、オープンにされていないようなので、これでずっとうまくいくかという不安はあるのですが、まあ、今のところ良さそうなのでこのまま行ってみようと思います。

これでソースファイル数は半分ぐらいになりそうです。