AutoCAD VBAからExcelを強制召喚せよ：OSレベルで制御するウィンドウ・オーケストレーション
AutoCADのバックグラウンドで黙々とデータを書き出すExcel。しかし、処理が終わった瞬間にユーザーがそのExcelを見つけられず、二重起動やデータ競合を招く……。これは、中途半端なCOM操作に依存しているエンジニアが必ず陥る「運用の死角」だ。
本稿では、VBAの皮を被りながらWindows OSの深淵に触れる手法、すなわちWindows APIによるウィンドウ制御を用いた、確実かつエレガントなExcel呼び出しの極意を伝授する。
—
なぜCOMの `AppActivate` では不十分なのか
多くの初学者は `AppActivate` やExcelの `Application.Visible = True` でウィンドウを制御しようとする。だが、これはOSのウィンドウスタックを無視した「お願い」に過ぎない。特に複数のAutoCADインスタンスやバックグラウンド処理が絡む現場では、フォーカスは簡単に奪われ、ユーザーは「処理が終わったのか？」と不安を募らせる。
真のエンジニアは、OSが管理するウィンドウハンドル（HWND）を直接叩く。これが、システム間連携における唯一の正解だ。
—
実装の核心：FindWindowとSetForegroundWindow
Windows APIを活用すれば、Excelのプロセス名やキャプションをキーに、メモリ上のウィンドウハンドルを特定し、強制的に最前面へ引きずり出すことができる。
1. API宣言と構造の最適化
標準モジュールに以下のコードを記述する。ここでは、後のメモリリークを防ぐための設計も意識する。
‘ 64bit/32bit両対応のポインタ定義
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 SetForegroundWindow Lib “user32” (ByVal hwnd As LongPtr) As Long
Private Declare PtrSafe Function ShowWindow Lib “user32” (ByVal hwnd As LongPtr, ByVal nCmdShow As Long) As Long
Else
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Declare Function SetForegroundWindow Lib “user32” (ByVal hwnd As Long) As Long
Private Declare Function ShowWindow Lib “user32” (ByVal hwnd As Long) As Long
End If
Private Const SW_RESTORE As Long = 9 ‘ 最大化・最小化されたウィンドウを元に戻す
2. Excelを最前面に呼び出す関数
単にフォーカスするだけでなく、最小化されていた場合を考慮し `ShowWindow` を併用するのが、熟練の保守設計だ。
Public Sub BringExcelToFront(Optional ByVal ExcelCaption As String = “Microsoft Excel”)
Dim hWnd As LongPtr
‘ Excelのウィンドウハンドルを検索 (クラス名またはキャプション)
‘ “XLMAIN”はExcelのウィンドウクラス名
hWnd = FindWindow(“XLMAIN”, vbNullString)
If hWnd <> 0 Then
‘ 最小化されていたら復元
Call ShowWindow(hWnd, SW_RESTORE)
‘ 最前面に強制配置
Call SetForegroundWindow(hWnd)
Else
MsgBox “Excelが起動していません。”, vbExclamation
End If
End Sub
—
チーフアーキテクトからの警鐘：メモリとライフサイクル
このコードを実装する際、以下の3点に注意を払わなければならない。
1. オブジェクトの明示的解放:
`GetObject` や `CreateObject` でExcelを操作した後は、必ず `Set xlApp = Nothing` を実行すること。VBAのガベージコレクションを信用してはいけない。AutoCADのプロセスが終了しても、Excelのゾンビプロセスがメモリを食いつぶすのは、この解放漏れが原因だ。
2. APIの非同期性:
`SetForegroundWindow` はOSのセキュリティポリシーにより、特定の条件下では無視されることがある。しかし、我々がAutoCAD（メインスレッド）から呼び出す分には、高い確率で成功する。万が一失敗する場合は、`AttachThreadInput` APIを用いて入力アタッチを行う必要があるが、それはまた別の領域の深淵となる。
3. レガシー環境の保守:
`PtrSafe` キーワードを忘れるな。AutoCAD 2010以前と最新版が混在する環境では、コンパイル条件付きコンパイル定数 `#If VBA7 Then` が命綱となる。
—
結論：技術は「振る舞い」まで制御して完成する
AutoCADの業務自動化において、データの転送は「通過点」に過ぎない。ユーザーが次に何をすべきかを、システムが物理的に提示する。この「配慮」こそが、自動化システムを単なるスクリプトから「生産性向上ツール」へと昇華させる。
APIというOSの深層に触れることは、リスクを伴う。しかし、そのリスクを掌握した時、AutoCAD VBAは単なるCAD制御言語を超え、Windows環境全体を統御する最強のツールへと進化する。
さあ、コードを書き換えろ。あなたのシステムに「生命」を吹き込むのだ。
