「Excel VBA」異なるバージョンの利用者に配布するときの注意点

先日、CSVファイルを読み込んで帳票を印刷するツールを、Excel 2010（64bit版）で作成しました。

ツールの作成は無事に終わりましたが、運用テストで問題が起きました。ユーザーのExcelが「2007（32bit版）」のため思うように動かず、迷惑をかけてしまいました。

作成したツールは「リボンUI」や「テーブル機能」を使用していましたが、これらの機能はExcel 2007から搭載されています。見た目も2010と似ており、おそらく動くだろうと甘く考えていました。

今回はExcel VBAで作成したツールを、別のバージョンのExcelで動かすためのポイントをまとめました。

事前にユーザーの環境を確認する

Excelの搭載機能はバージョンよって異なります。特に「リボンUI」や「テーブル機能」が搭載された2007以降は、2003以前とは大きな差があります。

開発前にユーザーが使用しているExcelのバージョンを確認し、可能であれば同じ環境で開発することが一番確実な方法です。

ライブラリの参照設定は必要最小限に

Excelファイルの配布前に、未使用の参照設定は外しておきます。

FileSystemObject（ファイル・フォルダ操作）やADO（DB接続）などのライブラリを使用する際に「参照設定」しておくと、入力候補の表示や実行前のエラーチェックが可能なため、効率良く開発できます。

しかし、参照設定を含むファイルを他のPCで開くと、コンパイルエラーになる場合があります。通常は実行環境に合わせてライブラリのバージョンも置換されますが、上手くいかないこともあるようです。

今回は「Mid」関数のところでコンパイルエラーとなりました。配布用ファイルでは不要となっていた参照設定をすべて外したところ、この問題は解消しました。

必要なライブラリの参照設定が原因でエラーとなる場合には、参照設定をせずに「CreateObject」関数で実行時にオブジェクトを作成する方法もあります。

Dim fso As Object
Set fso = CreateObject("Scripting.FileSystemObject")

この場合、上で挙げた参照設定によるメリットはなくなり、開発効率は悪くなります。

互換性重視であれば、参照設定をした状態で開発を進め、完成直前に参照設定を解除して「CreateObject」に変更する方法もおすすめです。

Windows API関数は極力使用しない・使う場合はExcelの32bit/64bitを意識する

VBAに存在しない高度な機能を実現する場合に、Windows API関数を使用することがあります。使用前には「Declare」ステートメントによる宣言が必要ですが、この宣言が厄介で「Excel」が64bit版の場合は記述が異なります。

私は条件付きコンパイルで「Excel」の32bit/64bitを判断し、有効なコードを環境ごとに切り替えるようにしています。

' Excel 64bit用
#If Win64 Then

Public Declare PtrSafe Function SetForegroundWindow Lib "user32" Alias "SetForegroundWindow" ( _
    ByVal Hwnd As LongPtr) As Long

' Excel 32bit用
#Else

Public Declare Function SetForegroundWindow Lib "user32" Alias "SetForegroundWindow" ( _
    ByVal Hwnd As Long) As Long

#End If