Visio VBAの深淵：数千のシェイプを「フリーズさせず」に制御する進捗UIの極意
Visioというソフトウェアは、その構造上、複雑な図面を扱う際に極めて「重い」挙動を示す。数百ページに及ぶドキュメントや、数千のシェイプをループ処理する際、VBAをデフォルトのまま走らせれば、Windowsは容赦なく「応答なし」のラベルを貼り付ける。
これは単なるUIの問題ではない。システムアーキテクトとして、「ユーザーに制御を委ねる感覚を奪わないこと」は、信頼性の高い自動化ツールの絶対条件だ。
本稿では、`Application.StatusBar`と`DoEvents`を軸に、メモリの断片化を防ぎつつ、プロフェッショナルな進捗可視化を実装する技術を伝授する。
—
1. 「応答なし」を回避する真のDoEvents戦術
`DoEvents`は単にUIを更新するための魔法ではない。OSからのメッセージキューを空にするための「呼吸」だ。しかし、闇雲にループ内で`DoEvents`を呼び出せば、コンテキストスイッチのオーバーヘッドにより処理速度は劇的に低下する。
極限の知見： 全ての反復処理で`DoEvents`を呼ぶ必要はない。例えば、1,000シェイプを処理するなら、50〜100回に1回、あるいは1%の更新タイミングでのみ呼び出すのが最適解だ。
2. 実装：洗練された進捗可視化モジュール
以下に、再利用可能な進捗管理の雛形を示す。ここでのポイントは、オブジェクトの参照を最小限に抑え、`StatusBar`の更新頻度を制御することだ。
‘ プロフェッショナル仕様：進捗管理用プライベートメソッド
Private Sub UpdateProgress(ByVal current As Long, ByVal total As Long, Optional ByRef lastUpdate As Single)
‘ 1%以下の刻みでは更新しない（パフォーマンス最適化）
Dim percent As Single
percent = current / total
If percent – lastUpdate < 0.01 Then Exit Sub ' ステータスバーへの出力 Application.StatusBar = "処理中: " & Format(percent, "0%") & " (" & current & "/" & total & ")" ' メッセージキューの解放 DoEvents lastUpdate = percent End Sub ' 実行例：数百ページのシェイプを走査する Public Sub ProcessLargeDocument() Dim pg As Visio.Page Dim shp As Visio.Shape Dim totalShapes As Long Dim currentShape As Long Dim lastUpdate As Single ' 事前計算：処理対象の総数を取得しておく（UIの正確性のために必須） totalShapes = 0 For Each pg In ActiveDocument.Pages totalShapes = totalShapes + pg.Shapes.Count Next ' 処理開始 For Each pg In ActiveDocument.Pages For Each shp In pg.Shapes ' --- ここに重い処理を記述 --- currentShape = currentShape + 1 UpdateProgress currentShape, totalShapes, lastUpdate Next Next ' 終了後の後始末 Application.StatusBar = "処理完了" ' メモリ最適化：明示的な解放 Set shp = Nothing Set pg = Nothing End Sub ---
3. メモリとオブジェクトライフサイクルの最適化
Visio VBAのメモリリークの大部分は、「暗黙のオブジェクト参照」によるものだ。特に`For Each`ループ内でシェイプを生成・破棄する場合、VBAのガベージコレクタは即座には働かない。
- 明示的解放の徹底: 巨大なループ内では、一時的に生成した`Shape`や`Page`オブジェクトは、処理が終わるたびに `Set obj = Nothing` を行うのが鉄則だ。
- イベントの抑止: 処理中は `Application.ScreenUpdating = False` および `Application.DeferRecalc = True` を活用せよ。これだけで実行速度は数倍に跳ね上がる。ただし、`DoEvents`を呼び出す際には、描画を一時的に戻す工夫が必要になる場合がある点に注意が必要だ。
4. レガシー環境とWindows APIの境界線
もし、より高度な「キャンセルボタン付きのプログレスバー」が必要であれば、VBAのフォーム（UserForm）を呼び出すことになる。しかし、モーダルフォームを表示したままだと、Visioのメインループと競合することがある。
その場合、`User32.dll`の`GetMessage`や`PeekMessage`をAPIで叩き、メッセージループを自前で制御するという手法をとるのがシニアエンジニアの領域だ。だが、まずは本稿で示した`StatusBar`の実装で、安定性と可読性のバランスを取ることを推奨する。
アーキテクトからの助言
コードは「動けばいい」のではない。「ユーザーが待機時間を計算でき、かつPCのリソースを枯渇させない」ように設計されて初めて、それはエンジニアリングの成果物となる。
`DoEvents`と`StatusBar`を制する者は、Visio自動化の泥沼から抜け出せる。数万のシェイプを扱うプロジェクトであっても、この設計思想を貫けば、システムは極めて軽快に、そして優雅に動作するはずだ。
次は、この処理を「非同期」のように見せるための、Windows APIを使用したタイマー制御について深掘りしよう。技術の探求に終わりはない。
