変更された関数仕様

ExcelのVBAで文字列の解析を行う練習台として、COBOLのステップカウンタや構造解析、テストケース洗い出しツールをお遊びで作っていたことがある。そのついでに、当時2000年問題のCOBOLソースから怪しい部分を抽出しリストアップするツールを作ったことがある。

その前に、VBAの力を知らない人たちに魅力を教えるべく、以前作ったExcelVBAをデモしてみることにした。処理の中には、文字列のバイト数（ASCII、SHIFT-JIS）から文字数を引き、全角の文字数を取得する処理があった。

まずは一人に見せてみた。が、あれ？明らかに結果がおかしい。一度家に持ち帰って調べても問題はない。違いはExcelのバージョン(5と95)と、OSのバージョン（3.1と95)だけである。

翌日、Excel95のヘルプを確認して唖然。文字列の関数の仕様が変わっていたのだ。厳密に言えば、内部コードがｕｎｉコードになった、というべきなのだろう。結果、文字列のバイト数は文字数の倍にしかならず、全く違った結果が返っていた訳だ。

慌てて書き直したのは書くまでもないが、ときどき関数仕様が変更されることがある。Excel 2007 は大丈夫そうだが、それ以降はどうなることやら・・。

PCは高性能の方がいい

軽視されがちかもしれないが、大量のデータを扱う、色を塗る、書式を変える、などを行うなら高性能のPCの方がいい。

最近は極端にバランスの悪いPCは見かけない（知らないだけ？）ので、新規に購入する場合は

・メモリの量

・CPUの処理速度

を確認しよう。

メモリの量は、Windows 2000/XP で、Excel2003以前でも少なくとも512Mは欲しい。データ量が多いなら1Gあってもいいだろう。Vista/Excel2007は未調査である。

CPUはIntelならCoreDuoなど、１プロセッサだが複数プロセッサあるかのようなタイプの方がいい。Excelの処理で他の処理ができない、というのも困るだろう。

実際に使い出してからは

・タスクマネージャーでリソースの確認

を行ってみよう。

常駐プログラムはリソースをバカ食いしていることがよくある。私の経験上ではGoogle Desktopやgooアラートなど。常駐を解除するとすいすい動き出す、ということも珍しいことではない。

どうしてもリソースが足りないならメモリを足すのがいいが、一時的な逃げ道としてスワップ領域を増やすのもいい。

一般的には「そんな面倒くさいこと、やってられん」だろう。少しの手間でパフォーマンスは調整すれば向上することもよくあるのだ。こういうことをベンダーに対処を依頼すると数万～数十万の費用を請求されかねない。ならば防衛策として、やはりはじめから高性能ＰＣを入れておくのが無難、ではないだろうか。

このブログで答えが見つかっているのだろうか？

このブログは「自分の備忘録」的に始めた。元々はすべて紙に書いていたのだが、散逸したり、紙の大きさが色々だったり、整理する気がなかったりなので、情報を一箇所に集めるのにブログが便利だから利用していたのだ。

紙からの置き換えなので、手書きの図などは載せていない。私としては「ああ、そういうことがあったよな」「じゃあ、あのソースコード見ればいいや」ということはできるので、現在の記載レベルで充分だからだ。

一方、googleで「VBA」で検索した場合、過去はかなり上位で出てきたが、今は出てこない。「VBA 作法」なら先頭に出てくる。このブログへ到達するキーワードを見ていると切実に困っているのではないか？それをさっさと解決できた方がいいんじゃないか？と思えるのだ。その人たちが「概念は分かった。じゃあ具体的にどうするんだ？」と結局は問題の解決に至っていないことはあるのではないだろうか？

せっかくだからもう少しブレイクダウンして、問題の解決ができるようにしていこうかと思う。過去の記事の手直し、図の添付、可能なら具体的なコード、などを行っていく所存である。