Office64bit版対応に伴うVBAツールの作業で、おすすめの作業手順と気を付けたいこと！[No89]

VBAツールで「メモリが不足しています」と表示されたり、アプリが落ちたり、クラッシュしたりするようになったら、VBAツールのソースが64bit版にきちんと対応できていない可能性が考えられます。

そこで今回は、64bit版に対応させる際に陥りがちな危険事例と、その対処法についてお話したいと思います。そのような場面に直面した方にとって、この記事が参考になれば嬉しいです。

こんなときは気をつけよう～危険事例～

最近はMicrosoft Officeを32bit版から64bit版に変更することが多くなってきました。

そうすると、今まで32bit版のAccess、Excel、Word、PowerPointで作成していたツールを、64bit版でも正しく動作するように修正する必要が出てきます。

その修正作業の中でも、64bit版Officeの導入されたＰＣでツールを実行したり、「VBAProjectのコンパイル」を行い、エラーになった箇所をコード上で直したりする作業は危険が伴います。より具体的な危険事例を2つご紹介します。

事例1:

「VBAProjectのコンパイル」を行った際、「Declare Function FindWindow　・・・」の部分でエラーになり、「PtrSafe」を付けて「Declare PtrSafe Function FindWindow」に変更し、コンパイルを行うとエラーは発生しなかった。また、動作させてエラーも発生したなかったため、Office 64bit版対応を完了とした。

事例2:

Windows API 宣言時に「As Long」を「As LongPtr」に変更し、事例1と同様にエラーの有無を確認し、対応を完了とした。

どうして危険なの？

このような確認の方法で、簡単に「ＶBAツールを32bit版から64bit版に変更できた」と思い込むことが、どうして危険なのか。続いて、その理由についてお話します。

理由は大きく3つあります。

理由1:

64bit版PCで「Declare PtrSafe」のように「PtrSafe」の有無の確認をすると、表面上の確認だけが行われ、コンパイル時には、64bit版で文法的に「PtrSafe」が付いているか確認しているだけとなってしまうから。

理由2:

コンパイル時に問題がなくても、大量のデータを扱う処理では、エラーになることが想定されるから。32bitと64bitでは扱えるメモリが違うため、32bitの変数に64bitの値を代入するとクラッシュする。

理由3:

Windows APIを用いていないコードであれば問題はないと思うが、Windows APIを用いたコードでは問題が発生することが想定される。Windows APIでは32bitで利用されることもあるため、64bitで格納された変数を引数にして、そのAPIを使おうとするとエラーが起きたりクラッシュしたりする。これはコンパイルでは確認できないので、問題があることに気付きにくい。

これらの理由から、事例1、事例2で紹介したような確認方法で、「64bit版に変更対応が完了した」と断定することは危険だと言えます。