AutoCAD VBAを掌握する極限の知見：`Eval`メソッドでAPIの限界を突破せよ
AutoCAD開発の現場において、VBAは「手軽だが非力」というレッテルを貼られがちだ。しかし、それはVBAの正統な作法しか知らない者の言い分に過ぎない。
AutoCADの深淵には、VBAのオブジェクトモデルが到達できない機能が山ほど眠っている。それらを呼び出すための「禁断の鍵」、それが `AcadApplication.Eval`メソッド だ。
今日は、VBAからAutoLISPの強力な関数群を直接叩き、APIの限界を突破する技術を伝授する。これは単なる裏技ではない。複雑な図面操作を極限まで効率化するための、プロのエンジニアが持つべき「視界」の話だ。
—
なぜ、今さら「Eval」なのか？
VBAのAPIは、確かに直感的だ。しかし、システム変数の一部や、特定の隠しコマンド、あるいはAutoLISPでしか提供されていない高度な図形処理関数を呼び出そうとすると、途端に手詰まりになる。
ここで多くの開発者は`SendCommand`に逃げる。だが、`SendCommand`は実行タイミングが非同期であり、さらにコマンドラインの表示に依存するため、安定した自動化には不向きだ。
対して`Eval`は、AutoLISPの式を評価し、その結果をVBAへ直接戻り値として返す。 処理は同期的に完了し、コードのフローを乱さない。これが、堅牢なツールを作るための唯一の解だ。
—
堅牢な実装のためのアーキテクチャ
`Eval`を扱う際、最も注意すべきは「文字列の構築」だ。不適切な引用符（`”`）の扱いは、コードを崩壊させる。
以下のモジュールは、LISPの評価結果をVBAの型へ安全に変換し、エラーを握りつぶさないための設計パターンである。
実践的コード：LISP連携汎用ラッパー
Option Explicit
‘ ———————————————————
‘ @brief Evalメソッドをラップし、LISP式を安全に実行する
‘ @param lispExpr 実行したいLISPコードの文字列
‘ @return LISPの実行結果（Variant）
‘ ———————————————————
Public Function ExecuteLisp(ByVal lispExpr As String) As Variant
On Error GoTo ErrorHandler
‘ AutoCADのEvalメソッドを呼び出す
‘ 戻り値はLISPの実行結果としてVBAのVariant型に投影される
ExecuteLisp = ThisDrawing.Application.Eval(lispExpr)
Exit Function
ErrorHandler:
‘ 運用ログに記録し、呼び出し元へ制御を戻す
Debug.Print “Eval Error: ” & Err.Description & ” | Expr: ” & lispExpr
ExecuteLisp = Null
End Function
‘ 使用例：現在のシステム変数 “OSMODE” を取得し、VBA側で判定する
Public Sub CheckSnapSettings()
Dim result As Variant
‘ LISPの (getvar “OSMODE”) を実行
result = ExecuteLisp(“(getvar “”OSMODE””)”)
If Not IsNull(result) Then
MsgBox “現在のスナップ設定値: ” & result
End If
End Sub
—
開発現場で陥る「3つの罠」
このテクニックをプロダクション環境に導入する際、以下の3点に注意せよ。これを無視する者は、間違いなくバグの温床を生産することになる。
1. 引用符の二重化（エスケープ）問題:
LISP式内部で文字列リテラルを使う場合、VBA上では `””` と記述してダブルクォーテーションをエスケープする必要がある。可読性が落ちるため、複雑な式は変数に格納してから呼び出すか、定数管理を徹底すること。
2. 実行コンテキストの乖離:
`Eval`はドキュメントコンテキストで実行される。PaperSpace/ModelSpaceの切り替えや、ロックされたレイヤに対する操作は、VBA同様の権限チェックが働く。LISP側で `(command …)` を連発するのは避け、あくまで「情報の取得」や「計算」に限定するのが鉄則だ。
3. データ型の不一致:
LISPのリスト型 `(list 1 2 3)` を返した場合、VBA側ではそのまま配列として扱えない場合がある。LISP側で文字列に変換して返すか、個別に `nth` 関数で取り出すなど、型変換のロジックを必ず挟むこと。
—
結論：APIを支配する者が、現場を支配する
`Eval`は強力だ。しかし、過信してはいけない。
全ての処理をLISPで書くべきではないし、全ての処理をVBAだけで解決しようとするのも傲慢だ。
「VBAで制御フローを設計し、APIにないエッジケースをLISPで補完する」
このハイブリッドな思考こそが、AutoCAD業務自動化エンジニアとして次のステージへ進むための鍵である。さあ、この「魔術」を使い、退屈な定型業務を根こそぎ自動化してほしい。コードは語る。君がどれだけ深くAutoCADを理解しているかを。
