＞　My.Settingはプロジェクト独立？ - ダンボ 07/06/25-12:09 No.5703 )　　の続きです。

DirectGo.exeとDirectGoP.exeはフォームを持ったexeであり殆ど同一内容の表を表示します。
細かいことを言えば、特定の列を非表示にするとかヘッダーを非表示にするなどの違いはあります。

VB6で作成したときは深く考えずにDirectGo.exeとDirectGoP.exeで殆ど同じMsFlexGridをデザイン定義
しました。今回はDataGridViewで実装しますが、ちょっとはステップアップしたいです。
すなわち殆ど同じ内容のコントロールを別々なモジュールでデザインするのは悔恨の元だろうと。
細かい違いはロジックで調整可ですので、基本的な表定義は1箇所の共通モジュールで行いたい。
そこで両者の共通モジュールといえば、Common.vbなのですが、これは画面を持ちません。

案1．デザイナーを全く使わずすべてロジックで表を生成する関数をCommon.vbに持ち両者から呼ぶ。
案2．よねＫＥＮさんが示唆されたような定義dllを作成して、両者でインスタンスを起こす。

と考えました。案1はデザイナーを使わないことによるメンテナンスの悪さ(保守性)と製作時の
試行錯誤が長そうです。案2は私の技術力ではまだ実装方法がピンと来ていません。

案1が良いのか案2が良いのか、いや案3があるのかをご指導ください。

> 案1．デザイナーを全く使わずすべてロジックで表を生成する関数をCommon.vbに持ち両者から呼ぶ。
> 案2．よねＫＥＮさんが示唆されたような定義dllを作成して、両者でインスタンスを起こす。
> 案1が良いのか案2が良いのか、いや案3があるのかをご指導ください。

これから案3を試してみます。

案3．画面を持つクラスCommonDef.vbを新設して共通表の雛形をデザイナーで作成しておき、
DirectGo.exe,DirectGoP.exeでは、定義された表のインスタンスを使用する。
なお共通ファイルが2つできるのは嫌なのでCommon.vb内の関数・定義はすべてCommonDef.vb
に移してからCommon.vbを捨てる。

ちょっと心配なのが「DirectGo.exeの使用リソースは最小にする」に対してexeのメモリ量が
表に関して2倍になるのかって点です。多分New句コンパイル時点で定義部分はexeメモリには
反映されず、そのインスタンスである表部分だけがメモリ使用される筈ですよね？

案4．これって結局カスタムコントロールを作ればよいのでは？それならCommonGrid.vbを
新設してCommon.vbはそのままかな。