【AutoCAD VBA】「書き込めない絶望」を未然に防ぐ――ReadOnly判定による堅牢な防壁の構築
AutoCAD VBAでツールを開発する際、多くのエンジニアが陥る罠がある。それは「図面ファイルが読み取り専用（ReadOnly）である可能性」を無視した設計だ。
ユーザーがサーバー上の図面を不用意に開いた際、あるいは誰かが編集中でロックがかかっている図面に対して、君の書いたコードが強引に修正を加えようとすればどうなるか？ 処理の最後に「保存できませんでした」という無慈悲なエラーを吐き、数時間の作業が水泡に帰す。
これはバグではない。設計の怠慢だ。
今日は、プロのアーキテクトとして、`AcadDocument.ReadOnly`プロパティを軸にした、破壊的変更を許さない「堅牢なガードコード」の極意を伝授する。
—
1. なぜ「ReadOnly判定」を疎かにしてはいけないのか
AutoCADのオブジェクトモデルにおいて、`Document`オブジェクトは実行時のコンテキストそのものだ。`ReadOnly`プロパティは、単なる状態の確認ではない。その図面が「揮発性のデータ」なのか「永続化可能なデータ」なのかを分ける境界線である。
特に、以下の環境ではこの判定が必須となる。
- 共有ネットワークドライブ: 他のユーザーが閲覧しているだけでロックがかかる。
- PDM/PLMシステム連携: チェックアウトされていないファイルは強制的に読み取り専用として開かれる。
- 参照図面の確認: 誤操作による意図しない上書き保存を物理的に防ぐ必要がある。
—
2. 【プロダクションコード】堅牢なガードメカニズム
単に「if文で囲む」だけでは不十分だ。ツールが起動した瞬間に判定し、ユーザーに即座にフィードバックする。この「先制防御」こそが、業務効率化ツールの品格を決める。
以下に、実運用でそのまま使える設計テンプレートを提示する。
Option Explicit
‘ ———————————————————
‘ メイン処理のガード節
‘ ———————————————————
Public Sub ExecuteMyTool()
Dim doc As AcadDocument
Set doc = Application.ActiveDocument
‘ 【重要】処理の冒頭でReadOnly判定を行う
If IsDocumentWritable(doc) = False Then
Exit Sub
End If
‘ ここから先は書き込み可能な図面だけが到達できる聖域
Call PerformBusinessLogic(doc)
MsgBox “処理が完了しました。”, vbInformation
End Sub
‘ ———————————————————
‘ 読み取り専用判定ロジック
‘ 戻り値：Trueなら書き込み可能、Falseなら読み取り専用
‘ ———————————————————
Private Function IsDocumentWritable(ByRef targetDoc As AcadDocument) As Boolean
‘ ReadOnlyプロパティで判定
If targetDoc.ReadOnly Then
MsgBox “【警告】この図面は読み取り専用です。” & vbCrLf & _
“編集処理を実行することはできません。” & vbCrLf & _
“保存が必要な場合は、チェックアウトを行ってください。”, _
vbCritical, “操作の中断”
IsDocumentWritable = False
Exit Function
End If
IsDocumentWritable = True
End Function
‘ 実際の業務処理（例）
Private Sub PerformBusinessLogic(ByRef doc As AcadDocument)
‘ ここにレイヤー操作やエンティティ生成等のロジックを記述
Debug.Print “業務処理を実行中…”
End Sub
この設計のポイント
1. 関数の分離: `IsDocumentWritable`として判定ロジックを独立させることで、他のツールでも使い回せる保守性を確保している。
2. ユーザーへの明示: `vbCritical`アイコンを用いて、ユーザーに「これは単なる通知ではなく、操作が拒否された」ことを明確に伝えている。
3. 早期リターン（ガード節）: 処理の本丸に入る前に門前払いすることで、ネスト（入れ子）を深くせず、コードの可読性を維持している。
—
3. 現場で生き残るための「さらに一歩先」の知見
実務レベルのツールであれば、`ReadOnly`判定だけでは足りないケースがある。以下の観点も頭の片隅に置いておいてほしい。
- データベース連携時の排他制御: もしツールが外部DBに書き込む場合、図面が読み取り専用でなくても、DB側がロックされている可能性がある。`ReadOnly`判定と並行して、DB接続のテストを必ず行うこと。
- 保存忘れへの対策: `ReadOnly`でない場合でも、処理完了後に`doc.Save`を自動実行する設計にすべきか、ユーザーの判断に委ねるべきか。これはチームの運用ルールと相談すること。私の推奨は「保存するかどうかを最後にユーザーに尋ねる」実装だ。
- レイヤー/ブロックのロック状態: ファイル自体が読み書き可能でも、特定のレイヤーがロックされていれば操作は失敗する。複雑な処理を行う場合は、対象となるオブジェクトの `Lock` プロパティも併せてチェックする設計にアップグレードせよ。
最後に：エンジニアとしての心構え
「動けばいい」コードを書くのは学生の仕事だ。
プロフェッショナルは、「ユーザーが誤って操作する未来」を予測し、それを未然に防ぐコードを書く。
この`ReadOnly`判定は、その第一歩に過ぎない。君がこれから作るツールが、エラーという名のストレスを現場から排除し、本来の設計業務に集中できる環境をもたらすことを期待している。
さあ、エディタを開き、このガードコードを君のライブラリに組み込んでくれ。それが、優れた自動化の始まりだ。
