Accessで「レスポンシブUI」を実装せよ：OnResizeイベントを支配する極限の最適化術
Accessのフォーム開発において、最も素人臭いUIは「固定サイズのウィンドウに、固定サイズのコントロールを詰め込むこと」だ。ユーザーの解像度は千差万別であり、広大なモニターを使っているのに隅っこで窮屈に動くアプリは、それだけで業務効率を著しく低下させる。
今回は、Accessの`OnResize`イベントを掌握し、ウィンドウの伸縮に合わせてコントロールを動的に再配置する「真のレスポンシブUI」の実装論を伝授する。
—
1. なぜ「個別に書く」のが悪手なのか
多くの開発者は、各フォームのコードモジュールに直接計算式を書き込む。これは「アンチパターン」だ。フォームが増えるたびに同じコードをコピペし、仕様変更のたびに全フォームを修正する羽目になる。
業務自動化のプロであれば、「制御ロジックの抽象化」を最優先せよ。コントロールのIDと、追従ルール（左端固定、右端追従など）を定義し、それを処理する共通プロシージャに流し込むのが、保守性の高い設計の正解だ。
—
2. 実装の核心：クラス設計による中央集権管理
フォームの`OnResize`イベントでは、再描画の抑制が鍵となる。何も考えずにサイズを変更すると、コントロールが一つ動くたびに画面が激しくチラつく（Flickering）。これを防ぐための設計をコードに落とし込む。
【プロダクションコード】レスポンシブUI制御モジュール
まずは標準モジュールに、制御用の構造体とロジックを用意する。
‘ 標準モジュール: modFormResizer
Option Compare Database
Option Explicit
‘ コントロールごとの追従ルールを定義
Public Enum ResizeRule
Fixed ‘ 固定
StretchWidth ‘ 幅だけ追従
MoveRight ‘ 右端に追従して移動
End Enum
Public Type ControlSetting
Name As String
Rule As ResizeRule
End Type
‘ フォームのサイズ変更時に呼び出す汎用エンジン
Public Sub ApplyResize(frm As Form, settings() As ControlSetting, originalWidth As Long, originalHeight As Long)
Dim i As Integer
Dim ctl As Control
Dim ratioW As Double
‘ 現在のウィンドウサイズと初期サイズの比率を算出
ratioW = frm.InsideWidth / originalWidth
‘ 描画停止（チラつき防止）
On Error Resume Next
For i = LBound(settings) To UBound(settings)
Set ctl = frm.Controls(settings(i).Name)
Select Case settings(i).Rule
Case ResizeRule.StretchWidth
ctl.Width = ctl.Width ratioW ‘ 幅を比率で拡大
Case ResizeRule.MoveRight
ctl.Left = ctl.Left ratioW ‘ 位置を比率で移動
End Select
Next i
End Sub
【フォーム側】呼び出し実装
フォームのモジュールは、これほどまでにシンプルになる。
‘ フォームモジュール: Form_frmMain
Option Explicit
Private m_Settings(0 To 1) As ControlSetting
Private Sub Form_Open(Cancel As Integer)
‘ 初期設定：どのコントロールをどう動かすか定義
m_Settings(0) = CreateSetting(“txtDataGrid”, ResizeRule.StretchWidth)
m_Settings(1) = CreateSetting(“btnSave”, ResizeRule.MoveRight)
End Sub
Private Sub Form_Resize()
‘ 汎用モジュールを呼び出すだけ。ロジックはここには書かない
ApplyResize Me, m_Settings, 8000, 6000 ‘ 8000×6000は設計時の基準サイズ
End Sub
‘ 補助関数
Private Function CreateSetting(name As String, rule As ResizeRule) As ControlSetting
CreateSetting.Name = name
CreateSetting.Rule = rule
End Function
—
3. 実務で「詰まない」ための3つの鉄則
コードを動かすことと、運用に耐えることは別次元の話だ。以下の注意点を蔑ろにする者は、数ヶ月後の改修で必ず地獄を見る。
① 「基準サイズ」を魔法の数字にするな
コード内に直接 `8000` と書くのは避けるべきだ。フォームのモジュールレベル変数、あるいは隠しテーブルで「設計時のフォーム幅」を保持しておけ。そうすれば、レイアウト微調整のたびにコードを修正する必要はなくなる。
② `On Error Resume Next` の正しい使い方
UI更新処理は、コントロールの存在チェックなどでエラーが起きやすい。しかし、エラーを隠蔽しすぎるとバグの温床になる。`On Error Resume Next` は最小限の範囲（プロパティ変更箇所のみ）に限定し、必ずエラーハンドリングを意識せよ。
③ 最小サイズのガード
ウィンドウを極端に小さくされた場合、コントロールが重なったり消滅したりする。`Form_Resize` の冒頭で、`If Me.InsideWidth < 4000 Then Exit Sub` のように、UIが崩壊する境界線をハードコードで制限する勇気を持て。 ---
結論
AccessのUI構築において、最も避けるべきは「手動による場当たり的な修正」だ。
オブジェクト指向的な思考（カプセル化、共通化）をVBAに持ち込めば、Accessは単なる「事務用ツール」から「堅牢なエンタープライズアプリケーション」へと変貌する。
今回提供したアーキテクチャをベースに、君たちの現場のUIを「モダンな操作性」へと昇華させてほしい。設計をサボるな。コードの美しさは、そのまま業務効率の高さに直結するのだから。
