実はこれは昨日から自分でやろうと思った事なのですが。
ソフトウェアを作っていてプログラム言語によってはただ作るだけではなくて、作成した後にコンパイルという作業をしなければプログラムが動かないという言語があります。
意識はしていないのですがVBAもコンパイルが必要な言語です。
C言語などでは、プログラムは書いただけでは動きません。プログラムの内容をコンピュータに合わせて最適化した実際にプログラムを実行する実行ファイルを作成しなければなりません。その時に、プログラム内にエラーがあればコンパイル自体最後までできないので実行ファイルは作成されません。つまりエラーをゼロにしない限り一つも動作させることができない、というのが昔ながらのC言語でした。
厳密に作成することを意識することでより正確なプログラミングができるという意味ではこのような仕組みになっていることはいいことでした。その反面初心者には難しいという印象があったかもしれません。
私はプログラム自体よりもこのコンパイルという作業自体が苦手でした。コンパイルの方法も、速度重視なのか、安定性重視なのか、メモリをできるだけ使わないようにするのか、といったオプション設定もできたのですがそのオプション設定がかなり面倒だったので用意されているオプション設定のままそのままコンパイルしていたものです。
VBAのコンパイルは、実際に何をしているのかはブラックボックスですのでよく分かりません。ただ、初めて実行した時に一瞬でコンパイルが行われExcelであればVBAを作成しているExcelブックの中に実行ファイルを作っているようです。
コンパイルはVBEのデバッグメニューの中のVBAProjectのコンパイルをクリックすることによって行われます。一度実行しエラーが出すにコンパイルが成功した後に debug menu の中のVBAProjectのコンパイルを見てみるとグレーアウトしています。これでコンパイルされているかどうかを確認することができます。先に言った通り、実行させても実行前に一瞬で、自動でコンパイル実行されます。
ではわざわざデバッグメニューの中のVBAProjectのコンパイルすることは無意味なのでしょうか。
コンパイルをすることによって、単純なエラーがあるかどうかチェックすることができます。いきなり実行するとある程度のところまで動いたところで、エラーで止まったりするのですが、この途中で止まるということが実際にはVBA作成時にとても面倒なことで、例えばVBAの先頭で、EnableEventsでシートイベントが発動しないようにして、最後に発動するように再設定するようなこともよくやりますが、途中でプログラムが止まってしまったら、シートイベントが発動しない状態で止まってしまうので、シートイベントを発動させるようにイミディエイトウィンドウで手打ちで再設定してやらなければいけないので、開発がその都度やり直しになって、なんとなく嫌な思いになります。
こういったことをあらかじめ実行する前にコンパイルすることによってエラーがあるかどうかはっきりします。
数行しかないVBAだったり、マクロの記録で作成したVBAであればコンパイルの必要はないでしょうけど、ループや分岐があったり画面表示の更新を一時的に止めたりシートイベントを止めたりするようなマクロの場合はコンパイルするメリットは大きいのです。
コメント