【上級】Application.EventsEnabledを制御した無限ループ回避：イベント駆動型処理の安全な実装
Visio VBAにおけるイベント駆動型プログラミングは、図面上の動的な振動や外部システムとのリアルタイム連携を構築する上で極めて強力な武器だ。しかし、この武器の扱いを誤れば、システムは瞬時に破滅的な無限ループへ陥り、ExcelやVisioプロセス全体を巻き込んだフリーズを引き起こす。
特に、`Shape`のプロパティ変更イベント（例：`ShapeChanged` や `CellChanged`）の内部で、さらなる図形の変形やデータの書き換えを行う設計は、「イベントの連鎖（Event Cascading）」という悪夢の温床となる。
本稿では、Visioのオブジェクトモデルの深層に踏込み、`Application.EventsEnabled`プロパティを用いた鉄壁の無限ループ回避イディオムと、メモリ管理・パフォーマンスを極限まで最適化したイベントハンドリングの実装パターンを提示する。
—
1. Visioイベントモデルの暗部：なぜ無限ループが発生するのか
Visioのイベントシステムは、COM（Component Object Model）のコネクションポイントをベースに動作している。VBAで`Shape.Text`を変更したり、`Cell.FormulaU`を書き換えたりすると、Visioエンジンは即座にその変更を検知し、対応するイベントプロシージャ（例：`VisEventProc` やクラスモジュール内のイベント）を呼び出す。
ここで発生する構造的欠陥が、以下のシチュエーションだ。
1. ユーザーまたはプログラムがShape Aのシェイプデータ（Prop）を変更。
2. `ShapeChanged` イベントが発火し、イベントハンドラが起動。
3. イベントハンドラの処理内で、「整合性を保つため」にShape A（あるいは連動するShape B）の別のセルを書き換える。
4. この書き換え自体が新たな「変更」とみなされ、再び `ShapeChanged` が発火する。
5. 1に戻る（無限再帰）。
VBAのコールスタックが限界に達するか、CPU使用率が100%に張り付いて強制終了するまで、この連鎖が止まることはない。
—
2. 解決策：`Application.EventsEnabled` の真の挙動と限界
この問題に対する唯一無二の正攻法が、`Application.EventsEnabled` プロパティの制御である。
Application.EventsEnabled = False
‘ — ここで形状をプログラムから変更 —
Application.EventsEnabled = True
このプロパティを `False` に設定すると、Visioアプリケーションレベルですべてのイベントの発火が一時的に抑制される。バックグラウンドのCOMイベントキューが遮断されるため、コード内でどれだけ図形を改変しようとも、イベントハンドラが再入することはない。
【重要】シニアエンジニアが知るべき実装上の罠
1. 例外処理（Error Handling）の欠如によるデッドロック
`EventsEnabled = False` の状態で実行時エラーが発生し、そのままプロシージャが抜けた場合、Visio全体のイベントが無効化されたままになる（ユーザーが図形を動かしても何も反応しなくなるゾンビ状態）。必ず `On Error GoTo` で確実に復元させなければならない。
2. マルチスレッド非同期環境での無力さ
VBAはシングルスレッドで動作するため、同一コールスタック上の連鎖であれば `EventsEnabled` で完璧に防げる。しかし、外部COMアドインや別プロセスからの非同期コールバックが絡む場合、このフラグだけでは競合状態を防ぎきれないケースがある。排他制御フラグ（Reentrancy Guard）との併用が必須となる。
—
3. 実装パターン：イベントハンドラにおける安全な排他制御クラス
実務に耐えうる堅牢なコードとして、クラスモジュールを用いたイベント監視と、`EventsEnabled` / 排他フラグの二重防御による実装を示す。
前提条件
1. クラスモジュールを `C_VisioEvents` という名前で作成する。
2. ThisDocument または標準モジュールからこのクラスをインスタンス化する。
クラスモジュール：`C_VisioEvents.cls`
Option Explicit
‘ Visioのイベントをフックするためのクラス
Private WithEvents vsoApp As Visio.Application
‘ 再入防止用のローカル排他フラグ（マルチレイヤー防御）
Private m_IsProcessing As Boolean
Public Sub Init(ByVal appInstance As Visio.Application)
Set vsoApp = appInstance
m_IsProcessing = False
End Sub
‘ Shape変更イベントのハンドラ
Private Sub vsoApp_ShapeChanged(ByVal Sheet As Visio.IVShape)
‘ 1. ローカルの排他フラグによる高速ガード
If m_IsProcessing Then Exit Sub
‘ 2. アプリケーションレベルのイベント無効化による根本的ガード
On Error GoTo ErrorHandler
m_IsProcessing = True
vsoApp.EventsEnabled = False ‘ 全イベントをシャットダウン
‘ — ここから安全なイベント処理・図形操作ロジック —
‘ 例：特定のレイヤーにある図形を変更した場合、関連するメタデータを更新する
If Sheet.LayerCount > 0 Then
Call ProcessShapeBusinessLogic(Sheet)
End If
‘ —————————————————-
ErrorHandler:
‘ 3. いかなるエラーが発生しても必ずイベントを復元する
vsoApp.EventsEnabled = True
m_IsProcessing = False
If Err.Number <> 0 Then
Debug.Print “Error in ShapeChanged: ” & Err.Description
‘ ログ出力や上位への伝播処理をここに記述
End If
End Sub
Private Sub ProcessShapeBusinessLogic(ByVal shp As Visio.IVShape)
‘ この内部で shp.CellU(“Prop.Status”).FormulaU = “…” などの操作を行っても、
‘ EventsEnabled = False により無限ループは発生しない。
‘ オブジェクトの明示的な解放（メモリ最適化）
Dim cellObj As Visio.IVCell
Set cellObj = shp.CellsU(“Prop.LastModified”)
cellObj.FormulaU = “””” & Format(Now, “yyyy/mm/dd hh:nn:ss”) & “”””
‘ COMオブジェクトの参照リーク防止
Set cellObj = Nothing
End Sub
Private Sub Class_Terminate()
‘ 確実なクリーンアップ
Set vsoApp = Nothing
End Sub
標準モジュール：`M_Initializer.bas`
Option Explicit
Private g_EventHandler As C_VisioEvents
Public Sub StartMonitoring()
‘ 既存のインスタンスがあれば破棄
Set g_EventHandler = Nothing
‘ 新規作成してApplicationをバインド
Set g_EventHandler = New C_VisioEvents
g_EventHandler.Init Visio.Application
MsgBox “Visioイベント監視エンジンが正常に起動しました。”, vbInformation
End Sub
Public Sub StopMonitoring()
Set g_EventHandler = Nothing
MsgBox “Visioイベント監視エンジンを停止しました。”, vbInformation
End Sub
—
4. チーフアーキテクトからの実践的提言
1. COMオブジェクトの参照解放（メモリ最適化）の徹底
Visio VBAでは、`.CellsU` や `.Shapes` などのプロパティにアクセスするたびに背後でCOMラッパーオブジェクトが生成される。これをローカル変数に受けて解放し忘れると、VBAのガベージコレクションが追いつかず、長時間の運用でメモリリーク（Visioプロセスの肥大化）を引き起こす。上記のコード例の通り、使い終わったオブジェクトは `Set variable = Nothing` で明示的に解放せよ。
2. パフォーマンスへの配慮
`Application.EventsEnabled = False` は強力だが、これを頻繁に切り替えるとVisio内部のイベントキューの構築・破棄にオーバーヘッドが生じる。イベントハンドラの最上位でのみ一度だけ `False` にし、処理完了時に `True` に戻す（Try-Finally パターン）を厳守すること。
3. レガシー環境（Visio 2010〜2016等）における注意点
古いバージョンでは、イベントハンドラ内での特定のアクション（例：ウィンドウの強制再描画やモーダルダイアログの表示）が `EventsEnabled` の状態と競合し、クラッシュを引き起こすケースが確認されている。イベントハンドラ内ではUIをブロックする処理を一切行わず、データ構造の操作のみに徹するのがアーキテクチャ上の鉄則である。
無限ループとメモリリークの恐怖から解放された、堅牢で拡張性の高いVisioソリューションを構築してほしい。
