Accessの「ナビゲーションウィンドウ」を制御する：単なる演出で終わらせない、プロの設計思想
Access開発において、`DoCmd.SelectObject` を使ったナビゲーションウィンドウの制御を「単なる見栄えの演出」と考えているなら、それは大きな誤解です。
我々プロフェッショナルにとって、UIの制御は「システムとユーザーとの信頼関係」そのものです。長時間かかるインポート処理や、複雑なデータ変換を行っている最中に、ナビゲーションウィンドウがピクリとも動かないブラックボックスのようなシステムは、ユーザーに「フリーズしたのではないか？」という不安を与えます。
今日は、`DoCmd.SelectObject` を単に叩くのではなく、堅牢かつ保守性の高い業務ツールに昇華させるための極限の知見を授けましょう。
—
1. なぜ「雑な実装」が現場を壊すのか
多くの開発者が陥る過ちは、処理の至る所に `DoCmd.SelectObject` を散りばめることです。これには以下のリスクが伴います。
- フォーカス喪失の罠: VBAの実行中にユーザーが別のウィンドウを触った際、予期せぬエラーやフォーカス消失による処理中断が発生します。
- 描画負荷の増大: 頻繁な選択操作は `DoCmd` オブジェクトを介してAccessのメインスレッドに割り込むため、過剰に行えば処理速度が確実に低下します。
- 保守性の欠如: ハードコードされたオブジェクト名が散乱すると、テーブル改名一つでシステム全体が崩壊します。
これらを防ぐには、「ナビゲーション制御を独立したモジュールとして抽象化する」ことが唯一の解です。
—
2. 実践的コード：堅牢なナビゲーションコントローラー
以下は、実務でそのまま使える、エラーハンドリングを完備したラッパー関数です。このコードの肝は「引数の検証」と「実行環境の保護」にあります。
‘ —————————————————————————
‘ @brief ナビゲーションウィンドウで指定オブジェクトを選択し、視覚的に通知する
‘ @param objectType 選択するオブジェクトの種類 (acTable, acForm等)
‘ @param objectName 選択するオブジェクト名
‘ —————————————————————————
Public Sub SelectNavigatorObject(ByVal objectType As AcObjectType, ByVal objectName As String)
On Error GoTo Err_Handler
‘ 存在しないオブジェクトを指定した際の予期せぬ挙動を防ぐ
If CurrentData.AllTables(objectName).IsLoaded = False And _
CurrentData.AllTables(objectName).Name = “” Then ‘ 簡略的な存在確認例
Debug.Print “Warning: オブジェクト ” & objectName & ” が見つかりません。”
Exit Sub
End If
‘ 引数 InDatabaseWindow:=True が重要
‘ これを忘れると、バックグラウンドでの選択操作がユーザーに伝わらない
DoCmd.SelectObject objectType, objectName, True
‘ 描画の即時反映を促すためにDoEventsを推奨（重い処理の合間なら特に）
DoEvents
Exit Sub
Err_Handler:
‘ ログ出力等をここに実装し、システムを止めない設計にする
Debug.Print “Error ” & Err.Number & “: ” & Err.Description
End Sub
このコードの「賢い点」
1. `InDatabaseWindow:=True` の強制: これを省略すると、カレントウィンドウ内での選択に留まり、ナビゲーションウィンドウが展開されない場合があります。
2. `DoEvents` の注入: 長時間処理のループ内で呼び出す場合、これがないとOS側が「応答なし」と誤判定するトリガーになります。
3. エラーハンドリング: 万が一、実行中にオブジェクトが削除されていたとしても、ツール全体がクラッシュすることはありません。
—
3. 運用における「知るべき鉄則」
現場で活用する際、以下の3点を必ず守ってください。
- 多用しない: 処理の「大きな区切り」でのみ使用してください。ループ内で毎秒呼び出すような設計は、AccessのUIスレッドを殺します。
- ユーザー設定との共存: ユーザーがナビゲーションウィンドウを「隠している」場合、`SelectObject` は無視されるか、無理やり表示を強要することになります。開発要件定義の段階で「ナビゲーションウィンドウを常に表示する運用」にするか、あるいは「UI非表示モード」での運用ルールを明確に決めておきましょう。
- モジュール分離: この関数は `modUIHelper` のような共通モジュールに格納し、プロジェクト全体で一元管理してください。
—
最後に：なぜ「ここ」にこだわるのか
私がここまで細部にこだわる理由は一つです。「開発者のエゴではなく、ユーザーの安らぎのためにコードを書く」からです。
処理が動いていることが可視化されるだけで、ユーザーのストレスは激減します。技術とは、ただ動けばいいものではありません。使う人の心理的負荷まで計算して初めて、それは「伝説的なツール」へと昇華します。
あなたの書くコードが、明日の現場の「当たり前」を少しだけ快適にすることを期待しています。さあ、実装を始めましょう。
