CorelDRAW VBAの深淵：再帰的走査で「ネストの迷宮」を制圧する
業務自動化の現場で最も忌むべきは、「なぜか一部のオブジェクトだけ変換が漏れる」という謎のバグだ。CorelDRAWのデザインデータは、クリエイターの気まぐれによって、グループの中にグループが入り組む「深淵」のような階層構造を持っている。
君たちが単一のループで `ActivePage.Shapes` を回しているなら、それは今すぐ捨てろ。それでは「グループ化されたオブジェクト」の殻を破ることはできない。今回は、デザインの深部に潜むパスまで確実に到達し、属性を掌握するための「再帰的走査（Recursive Traversal）」の極意を伝授する。
—
1. なぜ「単純ループ」ではいけないのか
CorelDRAWの `Shape` オブジェクトには `Type` プロパティがあり、`cdrGroupShape` という値を持つ。このとき、その `Shape` 自体は単なる「器」であり、真のターゲットである曲線や矩形は、その内側の `Shapes` コレクションの中に隠れている。
再帰を使わないということは、階層の深さに依存した「場当たり的なコード」を書くことを意味する。そんなものは保守不可能だ。我々アーキテクトが目指すのは、「階層が何重になろうとも、すべてを平等に叩く」堅牢な設計である。
—
2. プロダクションコード：再帰的属性置換エンジン
以下のコードは、指定した親オブジェクトから内部を再帰的に掘り進み、すべてのパスの線と塗りを一括で置換する。この設計パターンを身につければ、属性操作だけでなく、パスの抽出や変換などあらゆるタスクに応用できる。
‘ 【メイン処理】選択範囲、またはページ全体から再帰的に走査を開始する
Public Sub ApplyGlobalStyle()
Dim sr As ShapeRange
Set sr = ActiveSelectionRange
‘ 選択範囲がなければ全オブジェクトを対象にするという安全策
If sr.Count = 0 Then Set sr = ActivePage.Shapes.All
ProcessShapes sr
End Sub
‘ 【再帰的核心】オブジェクトを走査し、グループなら再帰、そうでなければ属性を適用
Private Sub ProcessShapes(ByVal shapes As shapes)
Dim s As Shape
For Each s In shapes
‘ グループの場合は自分自身を再帰呼び出し
If s.Type = cdrGroupShape Then
ProcessShapes s.Shapes
Else
‘ ここが実際の業務ロジック
‘ 線を黒、塗りを赤に強制変更する例
On Error Resume Next ‘ 属性を持たない特殊形状での停止を防ぐ
s.Outline.Color.CMYKAssign 0, 0, 0, 100
s.Fill.UniformColor.CMYKAssign 0, 100, 100, 0
On Error GoTo 0
End If
Next s
End Sub
—
3. 現場で「生き残る」ための3つの知見
① エラーハンドリングの境界線
`s.Outline` や `s.Fill` は、オブジェクトの種類（ビットマップやOLEオブジェクトなど）によっては存在しない場合がある。`On Error Resume Next` をただ漫然と使うのではなく、「属性変更が可能なオブジェクトかどうか」を事前に型判定するのがプロの作法だ。`s.Type` をチェックし、`cdrCurveShape` や `cdrRectangleShape` 等に限定して処理を流すのが最も堅牢である。
② 再帰の深さとパフォーマンス
CorelDRAWのVBAにおいて、再帰処理はメモリを比較的消費する。極端に巨大で複雑なAIファイル（数十万オブジェクト）を扱う場合、スタックオーバーフローやパフォーマンス低下を招く。その場合は、`Application.Optimization = True` を処理の冒頭で宣言し、画面描画を停止させてから処理を実行せよ。
③ データベース/外部ファイル連携の罠
このツールを外部システムと連携させる場合、「ObjectID」の永続性に注意せよ。一度ファイルを保存して開き直すと、`Shape` のIDは変動する場合がある。外部DBで管理するなら、IDではなく「レイヤー名」や「オブジェクト名（メタデータ）」をキーにするのが、長期保守における鉄則だ。
—
最後に：自動化は「書き捨てる」ものではない
今回紹介した再帰処理の設計は、一度作ればどんなデザインデータにも汎用できる「コア」となる。
君たちが今日書くその数行が、明日、同僚の、あるいは未来の自分の3時間の作業を消し去る。エンジニアリングとは、そういうものだ。コードの美学を捨てず、しかし泥臭く確実に、デザインの深層を制圧してほしい。
何か不明な点があれば、次は「イベント駆動によるリアルタイム属性監視」について深掘りしよう。健闘を祈る。
