昨日の記事にて、メニュー項目とインスタンスをどうやって結びつけようかと思案していたのですが、１つの解決策を得ました。
どうもFormクラスをはじめとしたControl全般は、Tagというプロパティを持っており、そこにそのコントロールと関連性の高いオブジェクトを放り込むようです。Tagはobjectクラスとなっているため、なんでも保持できます。一般的には文字列を入れておき、イベント先でswitchなどを駆使して処理を行うらしいです（この考え方で合ってるのかな？）。
で、私はメニューリストのTagプロパティに、インスタンスの参照をそのまま放り込んでみました。イベントハンドラに登録されているメソッドでは、senderとなるオブジェクトを決め打ちとし、Form型にキャストして処理しています。本来、インスタンスの参照をあまり複数で管理すべきではないということは承知しているのですが・・・、こうしておくと初期化処理の部分でTagプロパティに参照を渡すだけでよく、楽なんですよねぇ・・・。
まぁ処理の都合上子フォームのTagプロパティには親フォームのメニューリストの参照を渡していたり。そうしないとメニューリストに項目を追加するたび、子フォームごとにイベント処理を書かなくてはいけないので邪魔くさいんですよね・・・。
まぁTagはおいといて、受け取ったイベントメソッド側でobjectクラスからFormクラスへキャストしているので、万が一イベントを送ってきたインスタンスがこちらの装丁しているクラスでなかったとしたらあっけなく例外を吐きます＾＾；　まぁ自分で管理している以上そんな処理は有り得ないのですが・・・、お行儀がいいとはとても言えませんね（苦笑）
これに関しては、VC#のコードデザイナのイベントメソッド自動生成に任せているからobject型になっているのであって、これを自分でメソッド書いてイベントハンドラに追加してやれば好きに出来るはず・・・と思っていたり。ちょっとまだイベントハンドラについては理解し切れていない部分があるので間違ってるかも知れないけど、おそらくそれで解決できるはず。
Formクラス以外はそのイベントメソッドを利用することを想定してないから、メソッドの引数自体をそうしてしまえばコンパイルの時点で明らかにおかしいものは弾けるしね。
ということでお行儀のいいソースにするためにそこは修正予定。ただ、自動生成しちゃったイベント登録部分ってのはpartialで隠されてる部分だからあんまり手動で消したくないのよねぇ・・・。リファクタで消えたっけ・・・？　それがネックだなぁ。
まぁ最悪手動で消すとして、これである程度保守性も確保できたかな。
こっから先はいよいよ実行処理のアルゴリズム実装かな。Timerによるサンプリングレート管理とデータのバインディング処理がネックになるかな・・・。とりあえずは実装モデルを考えないと！