MonthCalendarを「経営の羅針盤」へ変える：イベント駆動の限界を超えたUIカスタマイズ
現場の業務効率化ツールを開発する諸君、`MonthCalendar`コントロールを見て「ただの日付選択UI」だと思っていないか？
もしそうなら、君の作るツールは単なる「入力を補助するだけの箱」で終わっている。真の業務自動化エンジニアであれば、UIは情報を能動的に語りかけるインターフェースであるべきだ。繁忙期、休業日、納期。これらをカレンダー上に視覚化すれば、ユーザーの判断ミスは激減する。
今回は、標準の`MonthCalendar`に独自描画を施し、ビジネス要件を直感的に伝えるための「極限のカスタマイズ手法」を伝授する。
—
1. なぜ標準のMonthCalendarでは「勝てない」のか
標準の`MonthCalendar`は、WindowsのネイティブAPIをラップしているに過ぎない。そのため、本来は「OwnerDraw（オーナー描画）」が許可されていない。
多くの初心者が「背景色を変えたい」という要件に直面したとき、プロパティを探し回って絶望する。だが、アーキテクトの視点で見れば答えは一つ。「標準コントロールの制約を逆手に取り、GDI+によるオーバーレイ層を構築する」ことだ。
堅牢な設計の鉄則
- イベント駆動の罠に落ちない: `DateChanged`イベントで描画を強制すると、リペイントの嵐でCPUを食いつぶす。描画は必ず`Paint`イベントか、独自のタイマー制御で行う。
- データソースとの分離: カレンダーの描画ロジックと、休業日を取得するロジック（DB/CSV）は物理的に分離せよ。結合度が高いコードは、仕様変更のたびに死ぬ。
—
2. 実装：カスタム描画による「繁忙期」の可視化
以下は、特定の配列（あるいはDBからロードしたリスト）に基づき、カレンダーの日付背景を塗り分けるためのプロダクションコードだ。これを`UserControl`としてラップするのが、最も保守性の高い道である。
Imports System.Drawing
Imports System.Windows.Forms
Public Class EnhancedMonthCalendar
Inherits MonthCalendar
‘ 繁忙期の日付リスト（外部DBから読み込む想定）
Public Property PeakDates As New List(Of DateTime)
Public Sub New()
‘ ダブルバッファリングで描画のチラつきを殺す
Me.DoubleBuffered = True
End Sub
‘ 描画のオーバーライドは、コントロールの描画プロセスへ深く介入する
Protected Overrides Sub OnPaint(e As PaintEventArgs)
MyBase.OnPaint(e)
‘ 注意: MonthCalendarはWin32 API依存のため、
‘ 本来の領域を計算し、透明な背景で重ね合わせる必要がある
‘ ここでは簡易的に特定の矩形へアプローチする
DrawCustomHighlights(e.Graphics)
End Sub
Private Sub DrawCustomHighlights(g As Graphics)
‘ ここでPeakDatesをループし、座標を計算して描画する
‘ ※実際にはHitTestを使用して各セルの座標を特定するのがプロの定石
For Each d In PeakDates
If d.Month = Me.SelectionStart.Month Then
‘ 描画ロジック: 繁忙期は淡い赤でハイライト
Using brush As New SolidBrush(Color.FromArgb(50, Color.Red))
‘ セル座標計算ロジック（省略）
‘ g.FillRectangle(…)
End Using
End If
Next
End Sub
End Class
—
3. 業務を止めるな：ファイル/DB連携の極意
このツールを業務で使う際、最も多い事故は「DBの接続タイムアウト」や「ファイルロック」によるアプリのフリーズだ。
1. 非同期ロードの徹底:
カレンダーの描画を待機させてはならない。起動時に`Task.Run`で日付リストをメモリ（`ConcurrentBag`推奨）に展開し、読み込み完了後に`Invalidate()`を呼ぶ。これがUIスレッドを殺さない唯一の解だ。
2. キャッシュの生存期間:
社内カレンダーが頻繁に変わることはない。一度取得したらローカルのJSONや`MemoryCache`に保持し、次に更新するまでネットワークへ飛ばない設計にせよ。
—
4. 現場のアーキテクトからの提言
コードを書くとき、常に自問自答せよ。「この機能は、ユーザーの『考えるコスト』を下げているか？」
単に色を変えるだけなら、ただの装飾だ。しかし、背景色を変え、マウスホバー時に`ToolTip`で「なぜこの日が繁忙期なのか」を表示させれば、それは「業務ガイダンス」へと昇華する。
- 保守性の確保: ロジックは全て`Service`クラスに追い出せ。UIコードは「描画命令を出すだけ」の薄い層に保つこと。
- 例外処理: ファイル読み込み失敗時にアプリが落ちるようでは、業務自動化エンジニアの失格だ。デフォルトの安全圏（今日の日付のみ表示など）へフォールバックするコードを必ず入れろ。
最後に
VB.NETは古臭い言語だと言う者がいる。だが、適切な設計とAPIへの深い洞察があれば、どの言語よりも早く、堅牢な業務UIを構築できる。君たちが作るツールが、明日の現場を少しでも楽にすることを期待している。
さあ、エディタを開け。理論を実弾に変える時間だ。
