PowerPoint VBAの限界を突破せよ：Windows APIによる「防壁」の強制解除術
VBA開発において、`Application.DisplayAlerts = ppAlertsNone` は諸刃の剣だ。しかし、現場のシニアエンジニアなら知っているはずだ。これが効かない「見えない壁」が存在することを。
外部DBへの接続、ActiveXコンポーネントの初期化、あるいは署名のないアドインが発する「セキュリティ警告」。これらはVBAの実行スレッドとは独立したレイヤーで発生するため、VBAの制御下にはない。ここで足止めを食らい、夜間バッチが停止した経験がある者こそが、真のエンジニアへの道を歩み始める。
本稿では、PowerPointが抱える「制御不能なダイアログ」を、Windows APIの力で強制的にねじ伏せる極限の手法を伝授する。
—
1. なぜ `DisplayAlerts` では不十分なのか
VBAの `DisplayAlerts` は、あくまでPowerPointの「アプリケーション内」で発生する警告にのみ介入する。しかし、Windowsのメッセージループや、OSレベルでフックされるセキュリティ警告は、PowerPointのオブジェクトモデルの外側にある。
これに対抗するには、「監視者（Watcher）」を別プロセスのように振る舞わせる必要がある。VBAのメインスレッドを止めずに、非同期でダイアログを検知し、即座に「Yes」を送り込む。これこそが、レガシー環境を生き抜くための唯一の解法だ。
—
2. API実装のアーキテクチャ
Windows APIの `FindWindow` と `SendMessage` を使用する。`FindWindow` でウィンドウクラス名とキャプションを特定し、`SendMessage` で `BM_CLICK` メッセージを送り込む。
実装コード：監視用標準モジュール
‘ API定義：メモリ管理と型安全を考慮した宣言
If VBA7 Then
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
Private Declare PtrSafe Function SendMessage Lib “user32” Alias “SendMessageA” (ByVal hwnd As LongPtr, ByVal wMsg As Long, ByVal wParam As LongPtr, ByVal lParam As LongPtr) As LongPtr
Else
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Declare Function SendMessage Lib “user32” Alias “SendMessageA” (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
End If
Private Const BM_CLICK As Long = &HF5
Private m_TimerID As LongPtr
‘ 警告ダイアログを自動クリックする監視ルーチン
Public Sub Watcher_Proc()
Dim hwnd As LongPtr
‘ 警告ウィンドウのクラス名とタイトルを指定（Inspect.exe等で調査必須）
hwnd = FindWindow(“#32770”, “セキュリティ警告”)
If hwnd <> 0 Then
‘ ボタンのID（通常は1）に対してクリックメッセージを送信
SendMessage hwnd, BM_CLICK, 0, 0
End If
End Sub
—
3. 非同期監視の極意：`OnTime` の罠と回避策
VBAの `Application.OnTime` は、正確には「スレッド」ではない。しかし、これを適切に配置することで、擬似的なマルチスレッド監視を実現できる。
重要なのは、「いつ監視を止め、いつメモリを解放するか」だ。
‘ 監視開始
Public Sub StartMonitoring()
‘ 0.5秒おきに監視を回す
m_TimerID = Now + TimeSerial(0, 0, 1)
Application.OnTime m_TimerID, “Watcher_Proc”
End Sub
‘ 監視終了（重要：実行後のクリーンアップを忘れるとメモリリークの元）
Public Sub StopMonitoring()
On Error Resume Next
Application.OnTime m_TimerID, “Watcher_Proc”, , False
End Sub
—
4. プロフェッショナルのための警告
この手法を運用に乗せる際、以下の3点だけは遵守せよ。
1. ウィンドウタイトルの動的判定: 日本語OSと英語OSが混在する環境では、`FindWindow` の引数（タイトル）を定数化してはならない。リソースファイルや設定シートから読み込むか、Windowクラスのみで特定するロジックを組むこと。
2. オブジェクトの排他制御: この監視処理が動いている間、別のダイアログ（本来ユーザーが確認すべきエラー）まで自動で「はい」を押して突き進むリスクがある。必ず処理のスコープを最小限に絞り、タスク完了後には即座に `StopMonitoring` を呼び出すこと。
3. エラーハンドリングの徹底: `SendMessage` が失敗しても、メイン処理のPPTX生成が停止しないよう、監視関数内は `On Error Resume Next` で厳重にガードする。
—
結論：技術は「回避」ではなく「制圧」するためにある
PowerPoint VBAの限界に直面したとき、多くのエンジニアは「仕様だから仕方ない」と諦める。だが、WindowsというOSの深淵を覗けば、そこには制御可能なメッセージの奔流がある。
APIを使いこなすことは、VBAの脆弱な枠組みを補強し、堅牢なエンタープライズシステムを構築することと同義だ。さあ、その警告ダイアログを黙らせ、自動化の極致へと進もう。
健闘を祈る。
