CorelDRAW VBAを掌握する：COMオートメーションにおける「死の連鎖」を断ち切る極限のメモリ管理術
CorelDRAWのVBA開発において、数千件のベクターデータを連続処理するバッチを組んだ際、中盤で決まって発生する「メモリ不足によるフリーズ」や「ゾンビ化したCorelDRAWプロセス」。これらはVBAの限界ではなく、「COMオブジェクトのライフサイクル管理」に対する認識の甘さが引き起こす必然的な帰結だ。
我々アーキテクトにとって、VBAは単なるスクリプト言語ではない。WindowsのCOM層を直接叩くためのインターフェースである。今回は、大規模バッチ処理を完遂させるための、妥協なきメモリオプティマイズとエラーハンドリングの極意を伝授する。
—
1. ゾンビプロセスの正体：暗黙の参照を根絶せよ
VBAで `Set doc = Application.CreateDocument()` と書いたとき、背後では何が起きているか。CorelDRAWのCOMサーバーがそのオブジェクトをメモリ上にロードし、参照カウントをインクリメントする。
問題は、`Set doc = Nothing` と書いても、「階層化された子オブジェクト」への参照が残っている場合、参照カウントがゼロにならないことだ。これが蓄積し、やがてメモリリークを引き起こす。
確実な解放のための「逆順クリーンアップ」パターン
オブジェクトは作成した順の逆順で解放し、明示的に Nothing を代入せよ。
Public Sub SafeBatchProcess()
Dim cdrApp As CorelDRAW.Application
Dim doc As CorelDRAW.Document
Dim sr As CorelDRAW.ShapeRange
On Error GoTo Cleanup
Set cdrApp = New CorelDRAW.Application
Set doc = cdrApp.CreateDocument()
‘ … 重い処理 …
‘ 処理終了後
doc.Close
Cleanup:
‘ エラー時も正常終了時も確実に解放する
If Not sr Is Nothing Then Set sr = Nothing
If Not doc Is Nothing Then Set doc = Nothing
If Not cdrApp Is Nothing Then Set cdrApp = Nothing
‘ ここで初めてメモリが解放される
End Sub
—
2. 禁断のWindows API：フリーズしたCorelDRAWを強制終了させる
どれだけ完璧なコードを書いても、サードパーティ製プラグインやCorelDRAW自体のバグでプロセスがハングすることはある。その際、タスクマネージャーを開くのは素人のやることだ。システム側からプロセスを握り潰す。
Kernel32を使用したプロセス強制終了
If VBA7 Then
Private Declare PtrSafe Function OpenProcess Lib “kernel32” (ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId As Long) As LongPtr
Private Declare PtrSafe Function TerminateProcess Lib “kernel32” (ByVal hProcess As LongPtr, ByVal uExitCode As Long) As LongPtr
Private Declare PtrSafe Function CloseHandle Lib “kernel32” (ByVal hObject As LongPtr) As LongPtr
End If
Public Sub KillZombieCorel(ByVal pid As Long)
Dim hProcess As LongPtr
hProcess = OpenProcess(&H1, 0, pid)
If hProcess <> 0 Then
TerminateProcess hProcess, 0
CloseHandle hProcess
End If
End Sub
※ `pid` は `Shell` 関数やWMI経由で取得したプロセスIDを指定する。この実装により、システム監視側に「異常終了検知→即時プロセス再起動」のループを構築できる。
—
3. 大規模バッチ処理における「再起動戦略」
CorelDRAWのVBAエンジンは、長時間稼働させるとガベージコレクションが追いつかず、メモリ断片化（フラグメンテーション）を起こす。これを回避する唯一の解決策は、「一定数処理したらプロセスごとリサイクルする」という設計だ。
処理の設計思想
1. ワーカープロセス分離: VBAは「命令を出すだけ」に徹し、処理本体は別プロセスのCorelDRAWに投げる。
2. ステータス永続化: 処理状況をテキストファイルやSQLite等の外部データベースに書き出し、フリーズ時はそこから再開する。
3. リミッター実装: 100ファイル処理ごとに `Application.Quit` させ、OS側にメモリを返却させる。
—
4. なぜ「DoEvents」は慎重に使わねばならないのか
`DoEvents` は、フリーズを防ぐための魔法の杖のように語られるが、実際は「再入可能性（Reentrancy）の地雷」だ。処理の途中でユーザーが別の操作を行えてしまうため、オブジェクトの整合性が崩れる。
大規模バッチ処理では、`DoEvents` をループ内に安易に配置せず、以下の条件を満たす場合にのみ使用せよ。
- 進捗プログレスバーを更新する場合のみ: 最小限の頻度（例：100回に1回）に制限する。
- ユーザーのキャンセル要求を検知する場合のみ: 処理のクリティカルなセクション外で行う。
—
アーキテクトの結論
CorelDRAW VBAの不安定さは、多くの場合、開発者が「メモリという有限のリソース」を管理できていないことに起因する。
- 変数のスコープを最小化する
- COMオブジェクトは常に親から子へと順に辿り、逆から解放する
- プロセス単位でのリサイクル設計を導入する
これらを徹底すれば、CorelDRAWは単なる「お絵かきソフト」から、堅牢な「ベクター自動生成エンジン」へと変貌する。コードの美しさは、メモリの解放順序に宿る。諸君の健闘を祈る。
