フォーム存在確認の「作法」：そのエラーハンドリング、まだ無駄なコストを払うのか
現場で長年、継ぎ接ぎだらけのレガシーシステムを解体・再構築してきた経験から言わせてもらえば、「実行時エラーをキャッチする」という考え方は、既に敗北である。
`DoCmd.OpenForm` を呼ぶ前に、対象のフォームがAccessのコンテナ内に実在するかを確認する。これは初心者が最初に学ぶべき防御的プログラミングの基礎だが、多くのエンジニアがその実装の「重み」を理解していない。
今日は、`CurrentProject.AllForms` を用いた、アーキテクトとして恥じないプログラミングの真髄を説く。
—
1. なぜ「エラーハンドリング」ではなく「事前確認」なのか
多くの開発者は `On Error Resume Next` で囲んで `OpenForm` を叩く。だが、考えてみてほしい。例外を発生させ、スタックトレースを生成し、VBAの実行エンジンにハンドリングさせる処理コストは、論理的な存在確認と比較してどれほど無駄か。
`CurrentProject.AllForms` コレクションは、Accessが保持する「フォーム定義」のメタデータへの参照だ。これを走査することは、メモリ上の構造体を確認するだけの極めて低コストな処理である。
推奨される実装パターン
‘ フォームを開く前に、実在性を厳密に検証する関数
Public Function SafeOpenForm(ByVal formName As String, Optional ByVal view As AcFormView = acNormal) As Boolean
Dim obj As AccessObject
‘ CurrentProject.AllForms はコレクションであり、For Eachによる走査が可能
‘ 存在しない名前を直打ちした瞬間の実行時エラーを完全に排除する
On Error Resume Next
Set obj = CurrentProject.AllForms(formName)
On Error GoTo 0
If obj Is Nothing Then
‘ ここでログを吐くか、ユーザーに通知する
Debug.Print “Warning: フォーム ‘” & formName & “‘ は定義されていません。”
SafeOpenForm = False
Exit Function
End If
‘ IsLoadedプロパティを確認し、既に開いている場合はフォーカスを当てるか再読み込みを検討する
If Not obj.IsLoaded Then
DoCmd.OpenForm formName, view
Else
‘ 既に開いている場合の挙動をここで制御する
DoCmd.SelectObject acForm, formName
End If
SafeOpenForm = True
End Function
—
2. メモリ最適化とオブジェクトライフサイクルの哲学
上記のコードを見て、「`obj` を明示的に解放しなくていいのか？」と感じた者は鋭い。
VBAの `AccessObject` は、COMポインタのラッパーに過ぎない。`Set obj = Nothing` を行うことは、GC（ガベージコレクション）に頼らず、自身が使用したリソースの所有権を即座に放棄することを意味する。レガシーなAccess環境において、メモリリークの温床は「解放されないオブジェクト参照」だ。
数千、数万回のループ処理でフォームの存在確認を行うような狂気的な設計は避けるべきだが、仮に行うのであれば、必ず `Set obj = Nothing` を忘れてはならない。
—
3. レガシー環境における「罠」とAPIの活用
時には、`AllForms` コレクションが正しく更新されていない、あるいは外部DBからのリンクが切れているという悪夢のような状況に直面することもあるだろう。その場合、Accessのメタデータ層ではなく、Windows APIレベルでのハンドル確認が必要になる。
だが、そこまで踏み込む前に、まずは「何が現在のセッション（`Application`）で見えているか」を正確に把握する癖をつけろ。
アーキテクトからの助言：
1. 文字列の正規化: `formName` にスペースや制御文字が混入していないか、常に `Trim()` を噛ませる。
2. 型定義の厳密化: `Variant` 型での受け渡しは、予期せぬ型変換を引き起こす。可能な限り `String` で型を縛れ。
3. システム連携への応用: このロジックは、外部から `Automation` を経由してAccessを操作する際にも応用できる。`CreateObject(“Access.Application”)` で起動したインスタンスに対して、確実にフォームが存在するかを確認してからメソッドを叩くことで、通信の安定性は劇的に向上する。
—
結論：コードは「対話」である
あなたが書く一文字一文字が、次にそのコードを触るエンジニア（あるいは未来の自分）との対話だ。「エラーが起きたら止まればいい」というスタンスは、プロフェッショナルの仕事ではない。
`AllForms` を使いこなすことは、Accessの内部構造を理解し、制御下に置くための第一歩だ。基礎を疎かにするな。細部に宿る「正確さ」こそが、堅牢なシステムを構築する唯一の道である。
さあ、今すぐ自身のコードを見直し、無意味なエラーハンドリングの嵐からシステムを解放せよ。
