プログラム

私はFarPoint社のSpread Sheetを多用します。

シートの行を削除したり、コピーやペーストをあちこちの画面（Form）で使いたくなります。このコードをそれぞれの画面で書いていたのでは、メンテナンス上よくありません。

VBでは、共通関数をModuleに書くことはできますが美しくありません。

コントロールに新しい機能追加する一つの方法は、そのコントロールを拡張するカスタムコントロールを作ることです。

しかしカスタムコントロールの作成は少し大げさでメンテナンスに手間取りそうなので別な方法を考えます。いま、これらの処理を受け持つクラス（仮にMySpreadとします）を一つ作ります。

FormではSpreadを配置し、Spreadのデザインやデータの入出力はすべてFormで処理します。MySpreadではSpreadに対応したContextMenuStripのインスタンスを作成し、右クリックしたときのプルダウンメニューの処理をこちらで行うことにします。

FormでMySpreadのインスタンスをつくり、Form上のSpreadとのリンクを付けておきます。

MySpreadの中で行削除や、コピーアンドペースト等のメソッドを準備してやれば、各Formでこれらのコードを書く必要はありません。

Public Class MySpread

    Private WithEvents m_Spd As FpSpread
    Private m_Sheet As SheetView

    Private m_ContextMenuStrip As New ContextMenuStrip
    Private WithEvents m_tsmi挿入 As New ToolStripMenuItem
    ' 　m_tsmiコピー、m_tsmi切取、m_tsmi貼付、 m_tsmi削除　等以下省略

    Private m_activeRow As Integer
    Private m_コピー元 As Integer
    Private m_コピー中 As Boolean

    Sub New(ByRef Spd As FpSpread, ByVal shtIdx As Integer)
        m_Spd = Spd
        m_Sheet = Spd.Sheets(shtIdx)

        m_tsmi挿入.Text = "挿入"
        m_tsmiコピー.Text = "コピー"
        m_tsmi切取.Text = "切取"
        m_tsmi貼付.Text = "貼付"
        m_tsmi削除.Text = "削除"

        m_ContextMenuStrip.Items.Add(m_tsmi挿入)
        m_ContextMenuStrip.Items.Add(m_tsmiコピー)
        m_ContextMenuStrip.Items.Add(m_tsmi切取)
        m_ContextMenuStrip.Items.Add(m_tsmi貼付)
        m_ContextMenuStrip.Items.Add(m_tsmi削除)
    End Sub

    Private Sub FpSpead_CellClick(ByVal sender As Object, ByVal e As FarPoint.Win.Spread.CellClickEventArgs) Handles m_Spd.CellClick
        If blninit = False Then Exit Sub
        activeRow = e.Row
    End Sub

    Private Sub tsmi挿入_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmi挿入.Click
        m_Sheet.AddRows(activeRow, 1)
    End Sub

    ' 	以下省略

    Private Sub tsmiコピー_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmiコピー.Click
    End Sub

    Private Sub tsmi切取_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmi切取.Click
    End Sub

    Private Sub tsmi貼付_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmi貼付.Click
    End Sub

    Private Sub tsmi削除_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmi削除.Click
    End Sub

End Class

実はこの話は以前ご紹介しました、[複数コントロールのセットを何度も使う]と内容的には同じことです。この原始的方法は、結構役立ちます。

とはいえOOPの工夫をもっと体系的に研究する必要があると考えています。デザインパターンを少し勉強しましたが、デザインパターンの技術を採用する場面が余りありません。

私のOOPの勉強は10数年前のJavaに始まり、確か2002年ころから.NETを使用してプログラムを書いていますので、特にVB.NETは目をつむっても書けるくらい慣れ親しんでいますが、デザインパターンはほんの一掴みほどしか利用していません。

理由がよくわかりません。一つには私が、デザインパターンを使いこなすほど勉強していないからだと思いますが、開発している内容も向き不向きがあるかもしれません。

ライブラリ等似たような話題が沢山あって、それらを体系的に構築しなければいけないケースでは、確かにインタフェース（に代表されるデザインパターンの技術）をうまく使う必要があると思います。が、10万行にも満たない事務アプリでは、似たようなクラスあるいは幾層もの階層をもったクラスを余り使いません。このようなケースでデザインパターンを使った高級な技術の必要性を感じていません。

それともう一つ現実的な問題として、そのプロジェクトに投入できる技術者の質と量の問題があると思います。マンパワーを十分かけた大きなシステムならいざ知らず、数万行のアプリケーションの作成では、高級な技術者がそろっているわけではありませんので、難しいコードを使うと後々メンテナンスの維持ができなくなる恐れがあります。その意味でできるだけ分かりやすい原始的コードを書く必要があります。

プログラムの評価の本で、[バグを抑えるためにはローテクを使え]というような文章を読んだことがあります。

確かにそうかもしれないと思っています。

だからといってデザインパターンのような体系的なプログラム技術が不要と言う訳ではありません。十分勉強して機会ある毎に利用すべきだと思います。

（ただし、趣味から言うと、私はデザインパターンより、泥臭いがしかし示唆に富んだJoshua Blochの[Effective Java]の方が好きで、さしあたり、この本を熟読玩味するところから始めようと考えています。）

私がコンピュータの世界に入ってFortranを少しかじった程度のとき、
先輩からLispで人工知能研究用のParserを作るように命じられました。
Fortranの逐語的プログラムは理解していましたが、
ポインタでつながったデータ構造やそれを操作するLispプログラムがいったい何をしているのか理解出来ず、
なにがどうなっているのか混沌の中で仕事をしました。

Lispは原則として逐語的コードではなく、すべては再帰コード（リカーシブコール）で処理します。
XSLTの再帰コードを書くとき役に立ちましたが、Lispとはそれ以来縁がなくなりました。

Lispから解放され、
Fortranで3Dグラフィックのプログラムを書いていましたが、
Fortranは何故かあまり好きではありませんでした。
パンチカードで1桁目はコメントフラグ、7桁目は継続行フラグ、
8桁目からコードを書くとかの約束事があまりにもカッタルかったからかも知れません
（今はこの制限は解除されていると思います）。
それとやはりプログラムの分岐の基本はgotoなので、
プログラムが読みにくかったからだと思います。

そういえば一時Prologという言語が人工知能の研究で注目され、
少し書いてみましたが、まとまった成果をあげることはできませんでした。

Wirthの[Algorithms + Data Structures = Programs]を読んだおかげで
Pascalを知ることができましたが、処理系を持っていなかったので、
後にデルファイに接するまでPascalを動かしたことがありませんでした。

その後パソコンが世の中に出現したとき、Cコンパイラも発売されましたので、
カーニハンのCを勉強しこちらは気に入り（多分Pascalの経験があったためと思います）、
始めははパソコンで、後にはUNIXでCのプログラムを結構長く書きました。

Cではポインタが面白く、データヒープの中をポインタを移動し、
そこでキャストするとintでもdoubleでもstructureでも抽出される仕組みが、
とても愉快で得意になって多用しました。
ポインタが関数呼び出しに使うなど痛快の限りです
（ご存知の通り、このポインターがプログラムを暴走される主要な原因でもあります）。

その後UNIXで大きなシステムに取り掛かりましたが、
当時はプログラムはすべて英数字のみで、変数や関数名の長さに制限がありましたので、
概してこれらの名前は無機的になり、コメントを適当に入れる作業は重要でした。

Javaは10年以上前に少しかじりました。
その後私はもうWindows一本で行こうと思っていましたので、Javaにふれることはなかろうと、
Javaの本は本棚の奥に積んいました。

実際私の周りではJavaを使う機会はあまりありません。
イントラネットではJavaを使うことはありますが、レンタルサーバでは大抵Javaは使えないし、
Windowsアプリケーションでは、まずJavaを使うことはありません。

突然（私にとっては突然）iPadが評判になり、私もMacがどんなものなのかと興味を持って、
Mac OSを購入しました。
最近のMacはUNIXベースだということだし、開発環境ではJavaがメインのようなので、
いたずらしてみたいと思ったのです。

しかし、購入した後でインターネットを調べると、MacOSを簡単にDOS V機にインストールできないことが分かりました。
Biosに代わるEFI-Xというブート用ハードを購入すればいいようですが、今のところそこまでやる気はありません
（EFI-XでMacを動作させるのは違法のようです）。

JavaはWindowsでは最近はNetBeansで練習プログラムを書いていましたが、
Eclipseが軽そうなのでEclipseに切り替えて、
暇をみつけてAndroidで携帯用のプログラムを作ってみようと考えています。
Eclipseは簡単にWindows（XP、Vista共）環境にインストールできました。

C#はJavaのいいとこ取りだから、C#を書くのとJavaを書くのと大差はなかろうと考えています。

昔Javaを勉強したとき、何故か習得に手間取りました。
一つは、アプレット等の話題が面白くなかったのと、
自分自身がオブジェクト指向の言語を始めて本格的に勉強したからだと思います
（その前に、C++を少し「勉強」したのですが、
VC++のフレームワークが余りにゴチャゴチャしていて嫌気がさしていました）。
それに何より必要に迫られていなかったので気乗りしませんでした。
加えて、当時はEclipseのような手ごろなIDEがなくて、
すべてコマンドを打っていたことも勉強がすすまない大きな要因だったかも知れません。

それでも「この際オブジェクト指向を習得しなければ」と思い私がとった方法は、
「やる気になるまで本を買う」ということで、次々に20冊程の本を買いましたら、
さすがに後には引けなくなり、なんとかものにすることができました。

勿論これは.NETプログラミングに、大いに役立ちました。

どちらにしても、これからはWindows以外もwatchしておいた方がよさそうだと考えています。

VB6のアップグレードの目処はついたのですが、細かいところに手間取っています。

一つは、古いプログラムでもFarPoint社のSpreadを使っているのですが、行と列の番号が1からスタートしていますし、
新しいものでは0からスタートしています。
従って、細かく調べないと新旧プログラムの計算結果が大きく異なります。

それは少し丁寧にプログラムを比較していけばいいことですが、
計算結果の微妙な相違を突き止めるのはもっとやっかいです。
このプログラムでは、お金の計算をしています。
1円1銭ほど細かい必要はありません。
概算でいいのですが、それでも二つのプログラムが少しでも違えば突き止めなければいけません。

どれだけ大きなお金の計算になるか分からなかったことと、
多分当時のデータ型の制限でお金の計算にダブル(Double)を使っています。
.NET環境では色々な種類のデータ型が用意されていますので、最終的には新しい環境で最適なデータ型を選択したいと思いますが、とりあえず二つの開発環境での計算結果の相違についての究明が急務です。

[VB6プロジェクトのアップグレード]は目処がついた。と思っていたのですが…

[Microsoft.Office.Interop]を使って、アプリケーションのデータをWordに書き出すこともExcelに書き出すこともできました。
これで終わりと思ったのですが、グラフを書く作業が残っていました。

VB6ではOLEオートメーションを使って、ここにExcelグラフを表示していたのですが、
VS2008ではOLEオートメーションはもはやサポートされていないようです。
[Microsoft.Office.Interop]を使う可能性を色々調べたのですが、結局どうすればいいか分かりませんでした。

VBアプリからVSTOをコールする方法があればこれがベストなのでしょうが、解答を見つけられませんでした。

となると残された方法は、クリスタルレポートかMicrosoftレポートのグラフを使う方法です。

色々試みてMicrosoftレポートでグラフを書くことができました。
しかし不満があります。できればクラス等のプログラムのデータを直接使いたいのですが、うまくいったのは一度DBに書き出してこれを使う方法です。
Microsoftレポートは、プログラミングの余地があまりありません。それにどうしたことかウィザードでデータセットにデータを読み込むことができませんでした。
ここを自前のコードに書き換えてなんとかグラフを表示することができました。

最低限の要求を確保しましたので、もう少しクリスタルレポートとMicrosoftレポートを研究したいと思います。

また、この場合やはりVSTOは使えないのか。
どうしても分からないときは、私はMSDNのフォーラムに質問を出します。
問題を整理してこのフォーラムに質問したいと思います。