クラスモジュール事始め

おそらく多くのVBAユーザーが「クラスモジュールの使い方がよく分からない」状態だと思います。

そこで、クラスモジュールの体験ができる手はずを書いてみます。

人にもよると思いますが、標準モジュールには「だいたいの用途別」に分けていませんか？「数字のチェック関数はこのモジュール」「シートの装飾はこのモジュール」など。それをしているならクラスファイルにはすんなり受け入れられるでしょう。

それをしていない人は、安易に手を出さない方がいいかもしれません。

---

さて、用途別に分かれているならクラスモジュールを追加し、どれか１つの標準モジュールを選び、まるまる内容をクラスモジュールにコピーします。クラスモジュールの名は「Class1」かと思います。いったんこのままで進めます。

もし、すべてPrivateのプロシージャや関数なら、呼び出せるようにPublicモジュールにしましょう。

---

次に標準モジュールを一つ追加します。これも特にモジュール名を変えなくていいです。

ここには

Public C as New Class1

と記載します。もし別にC　を使っているなら任意のもので結構です。

---

更に実験用に標準モジュールを追加します。

そこには

Public sub Test_1()

End Sub

と記載します。さてこのプロシージャ内で下の赤文字のように入力してください。

Public sub Test_1()

　　C.

End Sub

この　C．（ピリオド）を打った瞬間、先ほど作ったクラスファイルのプロシージャとファンクションが展開されます。リソース不足で展開されないこともたまにありますが・・。

これで元の標準モジュールと等価な処理がクラスファイルで使えます。

------------------------

で、「それってメリットあるの？」という質問が来そうです。

用途に分けてある、というところがミソでして

「数字のチェック関数はこのモジュール」　クラス名を　NUMCHK

「シートの装飾はこのモジュール」 クラス名を　SHTITL

などにしておけば、そのクラス群の中にあるのは例えば「数字チェック用関数」となりますので、関数名を長ったらしくしなくて済みますし、前方に修飾子が付くのでざっと眺めたときに「ここで何らかの数字のチェック」と、関数名を正確に読み取らなくてもよくなります。

つまり、クラス名さえ知っていれば保守時に可読性が上がり、作成時にもポップアップで出てきたとこから関数が探せ生産性が上がる、ということになります。

---

今回は体験、ということで分かりやすいよう常駐クラスを作りました。

通常クラスは「使うときに生成し、使い終わったら破棄する」のが一般的です。私もデータベースアクセスに使うクラスはそうしています。

VBAでは継承ができません。頻繁に使う共通処理的なものは今回の例のように常駐させておいた方が使いやすいでしょう。そのあたりのさじ加減は慣れてくればご自分で決められるでしょう。

次回はもう少しクラスファイルについて掘り下げてみます。


※書き直し　／八月末削除予定　／クラスモジュール基礎

計算が正しいとは限らない【懸賞付き】

もう随分前ですが、Pentiumのチップが計算ミスを起こすという話がありました。まだ2000年は超えていない時です。

今回はそういう話ではなく「なんか計算結果がヘン」という話題であります。

先日頼まれた修正で「ここの数字に係数を掛けてくれればそれでいいから」というシステムの改修がありました。話を聞くとたいしたことはありません。が、結構奥が深かったのです。

まず、改修にあたり確認すると、VBAで書いているところと、ワークシートに計算式を埋めているところがありました。そういえば話を聞いたとき、「両方使ってるけど、ワークシート関数の方が速い」とか聞いた覚えがあります。

そこはまあよかったんです。

で、VBAでの計算とワークシートの計算を比較したのですが、値が合わないのです。

結論からいいますと、ワークシート関数は正確でした。VBAは式を分ければ正解でした。実はちょっとくやしいのです。式を分けようが分けまいが、やはり同じ結果を返して欲しかった。こういうのがテクニックになるのがとても悲しく思います。

ただ、昔のエンジニアは事務計算か科学技術計算かは分かってプログラミングしてたと思うのです。私が式を分けた、というのはそういう過去の蓄積からなんとなく気付いたからにすぎません。

ここで質問です。

なぜCOBOLが「事務計算用」なのでしょう？

私の考えている解に近い方には、抽選で１名様に東京の新大塚か銀座の魚の旨い店でご馳走、ってのでどうでしょう。

地方からの人なら宿提供（男女ともにも安心して泊まれる場所は提供できます。都心からは少し離れているので・・）も可ですので。ただ、その際は時期は話し合いましょう。

まあ、そんなこんなでメッセージいただければと思います。

Accessから呼び出したExcelのSaveAsの挙動

Accessで管理しているデータをExcelの帳票（単票形式）で出力するシステムを引き継いだ。

さて、AccessからExcelを呼び出す際

・Create Objectを使う方法

・参照設定でExcelを定義しておく方法

がある。（他にもあるかも）

それぞれ短所長所があるのだが、私は図らずもCreate Objectを使う機会が多い。

今回引き継いだものは、上記を混在していた。メンテナンス上訳がわからなくなるといけないので、前者のパターンに統一してしまおうと、修正したときのこと。

処理が始まるとテンプレートファイルをワークファイルとしてコピーしてきて、値を貼り付け終わった後に正式ファイル名で保存しなおしていたのだが、修正後は正式ファイル名で保存する箇所でエラーが発生しだした。SaveAsメソッドのパラメータが間違えているのかと修正したりしたがＮＧ。

実験を重ねるうち、どうもSaveAsメソッド自体が使えないような気がしてきた。そこでテンプレートファイルをコピーしてきた際にワークファイルとせず、正式ファイル名にコピーして、最後はただのSaveに書き換えてみたところ、何事もなかったように終了した。

少なくとも参照設定の時は動作していたのだから、Create Objectではいくらか機能が制限されてしまうのだろうか？もし機能制限があるのなら参照設定の方が有利なのではないか、とも思う。

同様のご経験や、ご存知の方がいらっしゃれば情報を頂ければ有難いです。