権限と制御の境界線：CommandBarsを制し、AccessのUIを掌握する
Access開発の現場において、UIの動的制御を「なんとなく」で実装してはいないだろうか？
`Application.CommandBars` は、Office 2007以降のFluent UI（リボン）の影に隠れ、レガシーな存在と見なされがちだ。しかし、システム管理者やシニアエンジニアにとって、このオブジェクトは「UIをコードで直接ハックできる数少ない急所」である。
今回は、単なるボタンの無効化に留まらない、メモリの深層とWindows APIを絡めた「動的UI制御」の極限を探求する。
—
1. CommandBarsという「メモリの罠」
`CommandBars` は非常に強力だが、同時にメモリ管理の観点からは「危険なオブジェクト」だ。特に動的なメニュー生成を行う際、オブジェクトの解放（`Nothing`代入）を怠れば、Accessのプロセスが終了してもメモリ上に残骸が残り、次回の実行時に予期せぬ挙動を引き起こす。
我々プロフェッショナルは、「使用したオブジェクトは生成した順の逆で解放する」という鉄則を遵守しなければならない。
‘ 制御用プロシージャ：動的メニューの削除と再構築
Public Sub RefreshCustomMenu(ByVal UserRole As String)
Dim cmdBar As CommandBar
Dim ctrl As CommandBarControl
On Error Resume Next
‘ 既存のカスタムメニューを明示的に探索して破棄
Set cmdBar = Application.CommandBars(“MyDynamicMenu”)
If Not cmdBar Is Nothing Then
cmdBar.Delete
End If
‘ 新規作成
Set cmdBar = Application.CommandBars.Add(“MyDynamicMenu”, msoBarTop, False, True)
‘ 権限に応じたUI構築
If UserRole = “Admin” Then
‘ …コントロールの追加処理
End If
‘ メモリ最適化：参照の明示的解放
Set ctrl = Nothing
Set cmdBar = Nothing
End Sub
—
2. UIを「物理的に」支配する：Windows APIとの連携
`CommandBars` だけでは、リボン全体の非表示や、OSレベルでのウィンドウ制御には限界がある。例えば、特定の管理画面を開いている間、ユーザーにメインウィンドウの他のボタンを一切触らせたくない場合、`FindWindow` と `EnableWindow` APIを用いて、Accessの親ウィンドウを制御する手法が有効だ。
これは、サンドボックス化された現代のAccess環境において、最後の砦となる「力技」である。
If VBA7 Then
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
Private Declare PtrSafe Function EnableWindow Lib “user32” (ByVal hwnd As LongPtr, ByVal fEnable As Long) As Long
Else
‘ 32bit環境へのレガシー対応
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Declare Function EnableWindow Lib “user32” (ByVal hwnd As Long, ByVal fEnable As Long) As Long
End If
‘ 業務ロジック：特定処理中のUIロック
Public Sub LockApplicationUI(ByVal ShouldLock As Boolean)
Dim hApp As LongPtr
hApp = FindWindow(“OMain”, Application.Name)
‘ 0で無効化、1で有効化
EnableWindow hApp, IIf(ShouldLock, 0, 1)
End Sub
—
3. シニアエンジニアが守るべき「保守性の極致」
動的にメニューを制御する最大の敵は、「コードとUIの乖離」だ。実装者が変わった途端、なぜメニューが表示されないのか、なぜ特定のボタンが押せないのかがブラックボックス化する。
これを防ぐための、私の流儀を紹介する。
- プロパティとしての管理: 権限判定は必ず `CurrentDb` を経由した関数で行い、`CommandBars` 制御用クラスを作成してカプセル化すること。
- イベントのフック: `CommandBarButton` の `OnClick` イベントをクラスモジュールで実装し、ロジックを一元管理すること。標準モジュールに処理を散らしてはならない。
- バックアップ: 変更前のUI状態を退避させ、エラー発生時に瞬時にロールバック（復元）する機能を持たせること。
結論：技術は「制限」のためにある
ユーザーインターフェースを制御する目的は、ユーザーを縛り付けることではない。「ユーザーが迷わず、誤操作を起こさない環境を、コードの力で担保する」ことにある。
`Application.CommandBars` は古臭いAPIかもしれない。しかし、その内部で何が起きているかを理解し、メモリとプロセスを掌握できるエンジニアにとっては、今なお最強のUI制御ツールなのだ。
次回の開発でこのコードを実装する際、単に機能を実現するだけでなく、その背後にあるメモリの呼吸と、OSとの対話を感じ取ってほしい。それこそが、伝説を継承するエンジニアの条件である。
