Accessで「レスポンシブUI」を実装せよ：OnResizeイベントを制する極限の設計論
Accessのフォーム開発において、多くのエンジニアが「固定レイアウト」の呪縛に囚われている。ウィンドウサイズを変更しても、コントロールが孤立し、無駄な余白や隠れた項目にユーザーがストレスを感じる――そんな画面は、もはや時代遅れだ。
今回は、Access VBAの`OnResize`イベントを掌握し、モダンで洗練された動的UIを構築するための「プロフェッショナルな作法」を伝授する。
—
1. なぜ「ハードコード」してはいけないのか
初心者はコントロールの`Width`や`Top`を直接数値で指定しがちだ。だが、それは「技術的負債」の始まりに過ぎない。
- メンテナンス性の欠如: 仕様変更でボタンを一つ追加するたびに、全数値を計算し直すのか？
- イベントの暴走: `OnResize`はウィンドウ操作のたびに高頻度で呼び出される。ここで重い処理や無駄な描画を行うと、UIは途端にカクつき、ユーザー体験を損なう。
我々が目指すべきは、「基準値と相対比率」による自動計算ロジックである。
—
2. 堅牢なリサイズ処理の設計指針
レスポンシブを実現するための鉄則は以下の3点だ。
1. 初期値の保護: フォームロード時に「設計時のサイズ（初期値）」をモジュールレベル変数に保持する。
2. 描画の抑止: リサイズ中の再描画を最小限に抑える（`Echo`メソッドの活用は諸刃の剣だが、適切に使えば強力だ）。
3. モジュール分離: フォームごとにコードを書くのではなく、汎用的な「リサイズ制御クラス」または「標準プロシージャ」にロジックを寄せる。
—
3. 実践：プロダクション品質のコード
以下は、フォームのリサイズに合わせて「サブフォーム」と「保存ボタン」を動的に追従させるためのコードだ。
‘ フォームモジュール内に記述
Option Compare Database
Option Explicit
‘ 初期サイズを保持（マジックナンバー排除）
Private m_InitWidth As Single
Private m_InitHeight As Single
Private Sub Form_Load()
‘ フォームが開いた瞬間のサイズを基準値とする
m_InitWidth = Me.InsideWidth
m_InitHeight = Me.InsideHeight
End Sub
Private Sub Form_Resize()
‘ 極端に小さいウィンドウサイズでのエラーを回避
On Error Resume Next
‘ フォームの伸縮率を算出
Dim ratioW As Single, ratioH As Single
ratioW = Me.InsideWidth / m_InitWidth
ratioH = Me.InsideHeight / m_InitHeight
‘ コンポーネントの動的配置ロジック
‘ 例：サブフォーム(subMain)を右下へ拡張、保存ボタン(btnSave)を右下に固定
With Me
.subMain.Width = .InsideWidth – 200 ‘ 左右余白を確保
.subMain.Height = .InsideHeight – 1000
.btnSave.Left = .InsideWidth – .btnSave.Width – 300
.btnSave.Top = .InsideHeight – .btnSave.Height – 300
End With
End Sub
このコードの「プロのこだわり」
- `On Error Resume Next`の意図: リサイズイベントは極めて短時間に連続発生する。稀に描画タイミングと演算が衝突してエラーを吐くことがあるが、UIロジックにおいてこのエラーは致命的ではないため、安全側に倒している。
- マジックナンバーの排除: `200`や`1000`といった数値は、本来は`Const PADDING = 200`のように定義すべきだ。今回は可読性のために直書きしているが、大規模開発では定数化を徹底してほしい。
—
4. 現場で生き残るための「注意点」
サブフォームの描画負荷
サブフォームのリサイズは、中のクエリ再計算を誘発する可能性がある。もしリサイズが重いと感じたら、リサイズ処理の最後に `Me.Repaint` を呼ぶか、あるいはリサイズ中はサブフォームの `Visible` を一瞬 `False` にする工夫も検討すべきだ。
データベース連携の罠
フォームのサイズが変わったからといって、データ取得のクエリまで動的に変えてはいけない。UIのレイアウトとデータ取得ロジックは、徹底して分離（関心の分離）を行うこと。レイアウト変更はあくまで「見た目の最適化」に留めるのが、トラブルを未然に防ぐ唯一の解である。
—
最後に：エンジニアとしての矜持
AccessのUI構築は「レガシーな技術」と揶揄されることもある。しかし、VBAでウィンドウの挙動を完全に制御し、ユーザーが直感的に使えるツールを作り上げることは、紛れもなく高度な職人芸だ。
コードをコピペして満足するな。その先の、「なぜこの数値なのか」「どうすればもっと柔軟になるのか」という問いを常に持ち続けろ。その思考プロセスこそが、君をただの「Accessオペレーター」から「業務自動化アーキテクト」へと押し上げるはずだ。
次は、コントロールを再帰的に取得して一括リサイズする「汎用クラス」の実装に挑戦してみるといい。道は開ける。
