DoEventsの深淵：Excel VBAにおける「非同期」の幻想と、極限のパフォーマンス制御術
業務自動化の現場において、`DoEvents`は諸刃の剣だ。
「処理中にExcelがフリーズする」という末端ユーザーの嘆きに対し、思考停止でループ内に`DoEvents`を放り込むのは、プログラミングとは呼べない。それは単なる「その場しのぎ」だ。
真のエンジニアは、OSのメッセージキューとExcelのシングルスレッドモデルを掌握し、いかにして無駄なオーバーヘッドを排除しつつ、ユーザー体験を維持するかを極める。今日は、レガシー環境の最前線で戦う諸君に向けて、`DoEvents`の真実を説く。
—
1. DoEventsが引き起こす「隠れた死」
`DoEvents`は、OSがキューに溜め込んだメッセージ（マウス操作、描画要求など）をExcelのメインスレッドに処理させるための関数だ。だが、これを不適切な頻度で呼び出すことは、「CPUサイクルの無駄遣い」と「再入（Re-entrancy）によるスタック破壊」のリスクを孕んでいる。
DoEventsのコスト
`DoEvents`を呼び出すたびに、ExcelはOSのメッセージループをフックし、待機状態に入る。これを1ループごとに実行すれば、処理性能は劇的に低下する。10万行のループで毎回`DoEvents`を叩くなど、愚の骨頂だ。
—
2. 実践的制御術：間引きとOSネイティブの介入
パフォーマンスを落とさず、かつフリーズを回避する唯一の解は、「サンプリング実行」と「Windowメッセージの直接制御」である。
推奨される実装パターン
以下のコードは、カウンタを用いて「N回に一度だけ」メッセージを処理する手法だ。
‘ 伝説的なチーフアーキテクトが推奨する、オーバーヘッドを最小化したループ制御
Sub OptimizedLongProcess()
Dim i As Long
Dim total As Long: total = 1000000
Dim interval As Long: interval = 1000 ‘ 1000回に1回のみDoEventsを実行
Application.ScreenUpdating = False ‘ 画面描画の停止は鉄則
For i = 1 To total
‘ 重い業務ロジック
‘ … (Data processing)
‘ 最小限の頻度でOSに制御を戻す
If i Mod interval = 0 Then
DoEvents
End If
Next i
Application.ScreenUpdating = True
End Sub
—
3. レガシーの深淵：Windows APIを用いた「応答性」の確保
さらに高度な制御が必要な場合、`DoEvents`というブラックボックスに頼るべきではない。`User32.dll`を用いて、特定のウィンドウメッセージだけを明示的に処理させることが、真のエンジニアの流儀だ。
If VBA7 Then
Private Declare PtrSafe Function PeekMessage Lib “user32” Alias “PeekMessageA” (lpMsg As MSG, ByVal hwnd As LongPtr, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax As Long, ByVal wRemoveMsg As Long) As Long
Else
Private Declare Function PeekMessage Lib “user32” Alias “PeekMessageA” (lpMsg As MSG, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax As Long, ByVal wRemoveMsg As Long) As Long
End If
‘ メッセージキューを監視し、必要な時だけ処理する関数
‘ DoEventsの副作用（ユーザーによる二重実行など）を回避できる
Public Sub SafeProcessControl()
Dim Msg As MSG
‘ WM_PAINTやWM_MOUSEINPUTだけを拾うなどの高度な制御が可能
If PeekMessage(Msg, 0, 0, 0, 0) Then
DoEvents
End If
End Sub
—
4. 忘れてはならない「オブジェクトの死」
`DoEvents`で処理を継続させている間、メモリ上のオブジェクトは常に不安定な状態にある。特にCOMオートメーションや外部ライブラリを操作している場合、`DoEvents`の隙間にユーザーが「キャンセル」ボタンを押したり、別処理を走らせることで、インスタンスの不整合が起こる。
- 明示的な解放: ループ終了後は必ず `Set obj = Nothing` を実行し、参照カウントをクリアせよ。
- エラーハンドリング: `DoEvents`中に発生した例外を捕捉できるよう、ループ内には必ず `On Error GoTo` を配置し、例外発生時には `Application.EnableEvents = True` を保証するクリーンアップルーチンを用意すること。
—
アーキテクトからの提言
`DoEvents`は、いわば「麻酔」だ。患部（重い処理）を隠すために使うものであって、患部そのものを治療する手段ではない。
もし貴方の書いたコードで `DoEvents` が必須になっているのなら、まず疑うべきは「アルゴリズムの設計」と「不要なオブジェクト生成」だ。配列を使ったメモリ上での処理、`Range`アクセスの最小化、そしてAPI直叩き。これらを極めた先に、`DoEvents`を必要としない「真に滑らかな」システムが待っている。
コードは、ただ動けばいいのではない。OSの挙動を理解し、計算資源を慈しみ、ユーザーに違和感を与えない。それこそが、我々が目指すべき「自動化の極致」だ。
