【実務・中級編】DataGridViewのCellFormattingとCellParsingイベントの完全制御：日付や金額のカスタムフォーマット入力とバリデーションを両立させる実務手法 – Visual Basic (VB / VB.NET)解析バイブル

Visual Basic (VB / VB.NET)

2026.10.23

DataGridViewのCellFormattingとCellParsing完全制御：日付・金額のカスタムフォーマットとバリデーションを両立させる極限の実務手法

諸君、私はVisual Basicの奥深さに魅了され、数多の業務システムを設計・構築してきたチーフアーキテクトだ。
今日のテーマは、Windows FormsアプリケーションにおけるUIの要とも言える`DataGridView`の、`CellFormatting`と`CellParsing`イベントの「完全制御」だ。
巷にはこれらのイベントの断片的な情報が溢れているが、単に動けば良いというレベルでこれらを扱うと、予測不能なバグ、パフォーマンス劣化、そして何よりもユーザーにとって使いにくいUIという、三重苦を生み出す。

私は今日、単なるリファレンスの引き写しではない。オブジェクトのライフサイクル、パフォーマンスの重み、そして何よりも「堅牢で保守性の高いシステム」を構築するための、私の魂を込めた「極限の知見」を諸君に伝授しよう。
中級者諸君よ、安易なコードに溺れるな。真の業務効率化ツールは、細部に宿る設計思想によってその価値が決定されるのだ。

序章：なぜCellFormattingとCellParsingの「完全制御」が必須なのか

`DataGridView`は、データを表形式で表示・編集するための極めて強力なコントロールだ。しかし、その柔軟性ゆえに、安易な実装はすぐに破綻をきたす。特に、日付や金額といった、表示形式と入力形式が大きく異なるデータを扱う場合、その課題は顕著になる。

多くの開発者が陥る落とし穴はこれだ。

1. 表示と入力の乖離: ユーザーには「2023年10月26日(木)」や「¥1,234,567」と表示したいが、編集時は「2023/10/26」や「1234567」といったプレーンな形式で入力させたい。このギャップをどう埋めるか。
2. 安易なバリデーション: `CellParsing`で`Try…Catch`ブロックを乱用し、エラーを握りつぶしたり、ユーザーに不親切なメッセージを表示したりする。真のバリデーションは、ユーザーが直感的に間違いを理解し、修正できる仕組みを提供するべきだ。
3. パフォーマンスの軽視: これらのイベントは、スクロールやセルの再描画など、驚くほど頻繁に発生する。その中で重い処理を行えば、UIは瞬く間にフリーズし、ユーザーは苛立ちを覚えるだろう。
4. データモデルとの分離不足: 表示のためだけに基盤となるデータモデルの型を変更したり、ビジネスロジックとUIロジックが密結合したりする。これでは保守性が地に落ちる。

私が提唱する「完全制御」とは、これらの落とし穴を避け、以下の3つの要件を同時に満たす設計思想である。

ユーザーフレンドリーなUI: 表示は美しく、入力は直感的で間違いにくい。
堅牢なデータ処理: 不正な入力は許さず、データは常に正しい形式で保持される。
高パフォーマンス: 多数のデータでもUIが滑らかに動作する。

さあ、この知見を胸に、`DataGridView`の真の力を引き出そうではないか。

第1章：CellFormattingとCellParsingの真髄とデータバインディングの役割

まずは、これらのイベントがいつ、なぜ発生するのか、その本質を理解することから始めよう。

1.1. CellFormattingイベント：表示形式の制御

`CellFormatting`イベントは、セルが表示される直前、またはセルの値が変更されたときに発生する。その主な目的は、セルの表示形式を調整することだ。

発生タイミング:
`DataGridView`が描画される際（初回表示、スクロール、リサイズなど）。
セル内の値が変更された後。
引数: `DataGridViewCellFormattingEventArgs`
`Value`: フォーマット対象の元の値。この値を直接変更してはいけない。
`DesiredType`: セルに表示する値の望ましい型。
`CellStyle`: セルに適用されているスタイル。
`FormattingApplied`: イベントハンドラが値を正常にフォーマットしたかどうかを示すフラグ。`True`に設定すると、`DataGridView`のデフォルトのフォーマット処理はスキップされる。

重要な原則: `CellFormatting`イベントは、基盤となるセルの値を変更してはならない。あくまで表示のための変換に徹するべきだ。もしここで`e.Value`を書き換えてしまうと、データモデルそのものが意図せず変更されてしまうか、あるいは予期せぬ挙動を引き起こす。

1.2. CellParsingイベント：入力値の変換とバリデーション

`CellParsing`イベントは、ユーザーがセルを編集し、その編集が確定される（例えば、他のセルにフォーカスが移動する）際に発生する。その目的は、ユーザーが入力した文字列を、セルの基盤となるデータ型に変換し、必要に応じてバリデーションを行うことだ。

発生タイミング:
ユーザーがセルの編集を終了し、編集中の値がコミットされるとき。
引数: `DataGridViewCellParsingEventArgs`
`Value`: ユーザーが入力した文字列。
`DesiredType`: セルの基盤となるデータ型（通常は`DataGridViewColumn.ValueType`で指定された型）。
`InheritedCellStyle`: セルに適用されているスタイル。
`ParsingApplied`: イベントハンドラが値を正常にパースしたかどうかを示すフラグ。`True`に設定すると、`DataGridView`のデフォルトのパース処理はスキップされる。

重要な原則: `CellParsing`イベントでは、`e.Value`をパース後の正しい型の値に設定する。ここでエラーが発生した場合、`e.ParsingApplied = False`とし、適切なエラーハンドリングを行う必要がある。

1.3. データバインディングとの関係

`DataGridView`は、`DataSource`プロパティを設定することで、任意のデータソース（`DataTable`, `List(Of T)`など）にバインドできる。このデータバインディングの有無が、`CellFormatting`と`CellParsing`の挙動に影響を与える。

バインドされた列: `DataGridViewColumn.DataPropertyName`が設定されている列。セルの値はデータソースのプロパティと同期される。`CellFormatting`はデータソースの値を表示用に、`CellParsing`はユーザー入力をデータソースの型に変換する。
非バインド列: `DataPropertyName`が設定されていない列。セルの値は`DataGridViewCell.Value`プロパティに直接保持される。

本記事では、主にデータバインディングされた列を前提に解説を進めるが、その思想は非バインド列にも適用可能だ。重要なのは、データソースの型と、`DataGridViewColumn.ValueType`プロパティで指定するセルの基盤型を一致させることだ。これにより、`DataGridView`はデータ変換をより適切に処理できるようになる。

第2章：実務で直面する課題と安易な解決策の罠

さて、具体的な課題に踏み込もう。日付と金額、これら二つのデータ型は、表示と入力のギャップが大きく、開発者を悩ませる典型例だ。

2.1. 日付型 (DateTime) の課題

表示要件:
“YYYY/MM/DD (曜日)”
和暦（”令和5年10月26日”）
時刻を含まない形式（日付のみ）
空欄（Nothing/DBNull.Value）の場合、何も表示しない。
入力要件:
“YYYY/MM/DD”
“MM/DD” (年を自動補完)
“YYYYMMDD”
“YYYY-MM-DD”
空欄を許容。
不正な日付（例: “2023/02/30″）は拒否。

安易な解決策の罠:
`e.Value.ToString(“yyyy/MM/dd (ddd)”)`を`CellFormatting`に直接書く。これは良い。しかし、`CellParsing`で`DateTime.Parse(e.Value.ToString())`と書くと、ユーザーが”10/26″と入力した場合に正しくパースできない可能性があり、さらに`FormatException`が発生した際に、単純な`Try…Catch`で握りつぶしてしまうと、ユーザーはなぜエラーになったのか理解できない。

2.2. 金額型 (Decimal) の課題

表示要件:
通貨記号付き（”¥1,234,567″）
カンマ区切り
負数の表示（”-¥1,234,567″ または “¥(1,234,567)”）
ゼロの場合の表示（”¥0″ または空欄）
空欄（Nothing/DBNull.Value）の場合、何も表示しない。
入力要件:
カンマなしの数値（”1234567″）
カンマ付きの数値（”1,234,567″）も許容。
通貨記号付きの数値（”¥1234567″）も許容。
負数の入力（”-1234567″）
空欄を許容。
不正な入力（例: “abc”）は拒否。

安易な解決策の罠:
`e.Value.ToString(“C”)`を`CellFormatting`に書くのは良い。しかし`CellParsing`で`Decimal.Parse(e.Value.ToString())`と書くと、ユーザーが”¥1,234,567″と入力した場合に`FormatException`が発生する。`NumberStyles.Currency`を指定すればパースできるが、それでも不正な文字が混じった場合のハンドリングが不十分になりがちだ。

これらの課題に対し、我々チーフアーキテクトは、より洗練された「極限の知見」を適用しなければならない。

第3章：「極限の知見」に基づく設計原則

堅牢なシステムを構築するための設計原則をここで明確にしよう。これは、`DataGridView`に限らず、UI設計全般に適用できる普遍的な知見だ。

3.1. データモデルと表示ロジックの徹底分離

これは最も重要な原則だ。
基盤となるデータモデルは常に「素」の状態を保つべきである。
つまり、`DateTime`型は`DateTime`として、`Decimal`型は`Decimal`として、その変換されていない純粋な値を保持する。表示ロジックはUI層の責任であり、データ層やビジネスロジック層に侵食させてはならない。

`DataGridView`においては、`DataGridViewColumn.ValueType`プロパティで各列の基盤となる型を正しく指定することが、この原則を遵守する第一歩となる。そして、`CellFormatting`と`CellParsing`は、この「素」の値と表示文字列の間を橋渡しする役割を担うのだ。

3.2. カスタムフォーマッタ/パーサの導入とヘルパー関数の活用

複雑な変換ロジックをイベントハンドラ内に直接記述すると、コードは肥大化し、可読性と保守性が低下する。そこで、専用のヘルパー関数やクラス（カスタムフォーマッタ/パーサ）を導入し、ロジックをカプセル化する。

特に、`TryParse`パターン（例: `DateTime.TryParseExact`, `Decimal.TryParse`）を徹底的に活用し、例外ではなく戻り値で成功/失敗を判定する堅牢なパース処理を実装することが重要だ。これにより、入力バリデーションのロジックが明確になり、パフォーマンスも向上する。

3.3. バリデーションのタイミングとユーザーフィードバックの明確化

`CellParsing`イベントは、入力値の変換だけでなく、簡易的なバリデーションを行う最適なタイミングだ。

早期バリデーション: `CellParsing`で、入力が基盤となる型に変換可能か、またビジネスルール上妥当な範囲内にあるかをチェックする。
明確なフィードバック: バリデーションに失敗した場合、単にエラーメッセージを出すだけでなく、以下の対応を検討する。
`DataGridView.DataError`イベントを利用して、エラーの発生を通知する。
問題のセルにエラーアイコン（`DataGridViewCell.ErrorText`）を表示し、ユーザーが視覚的に問題を認識できるようにする。
必要であれば、元の値に戻すか、ユーザーに再入力を促す。

3.4. パフォーマンス最適化：イベント発生条件の厳格化

`CellFormatting`イベントは非常に頻繁に発生するため、その中で重い処理を行うと、UIの応答性が著しく低下する。

条件判定: `e.ColumnIndex`と`e.RowIndex`で対象のセルを特定し、必要な処理のみを行う。
値の型チェック: `e.Value Is Nothing`や`e.Value.GetType()`で、対象の値が期待する型であるかを確認する。
再描画の抑制: 複数セルの値を一括更新する際は、`DataGridView.SuspendLayout()` / `ResumeLayout()` を利用する。
編集モードの判定: `DataGridView.IsCurrentCellInEditMode`プロパティを利用し、セルが編集中かどうかで処理を分岐させ、編集中はプレーンな値を表示する（後述のコード例で詳細を解説）。

これらの原則を遵守することで、諸君のシステムは堅牢性、保守性、そしてパフォーマンスにおいて、盤石なものとなるだろう。

第4章：プロダクションコード例：日付・金額のカスタムフォーマットとバリデーション

それでは、具体的なコード例を通じて、上記の原則がどのように実践されるかを示そう。今回は、`Form`上に`DataGridView`を配置し、`DataTable`にバインドするシナリオを想定する。

4.1. データテーブルの準備

まず、サンプルデータを保持する`DataTable`を作成する。

.net
‘ Formクラスのメンバ変数として宣言
Private _dataTable As DataTable

Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
‘ データテーブルの初期化と列定義
_dataTable = New DataTable(“SampleData”)
With _dataTable.Columns
.Add(“ID”, GetType(Integer))
.Add(“ItemName”, GetType(String))
.Add(“OrderDate”, GetType(DateTime)) ‘ 日付型
.Add(“Amount”, GetType(Decimal)) ‘ 金額型
End With

‘ サンプルデータの追加
_dataTable.Rows.Add(1, “商品A”, #2023/10/26#, 1234567.89D)
_dataTable.Rows.Add(2, “商品B”, #2023/11/01#, 987654.32D)
_dataTable.Rows.Add(3, “商品C”, DBNull.Value, 50000.00D) ‘ Nullableな日付
_dataTable.Rows.Add(4, “商品D”, #2024/01/15#, DBNull.Value) ‘ Nullableな金額
_dataTable.Rows.Add(5, “商品E”, #2023/04/01#, 1000000000.00D)
_dataTable.Rows.Add(6, “商品F”, #2023/07/20#, -5000.00D) ‘ 負の金額

‘ DataGridViewへのバインド
DataGridView1.DataSource = _dataTable

‘ 列の初期設定（データ型を明確にする）
With DataGridView1
.AutoGenerateColumns = False ‘ 自動列生成はオフに推奨

.Columns.Add(New DataGridViewTextBoxColumn With {
.Name = “ID”, .DataPropertyName = “ID”, .HeaderText = “ID”, .ReadOnly = True
})
.Columns.Add(New DataGridViewTextBoxColumn With {
.Name = “ItemName”, .DataPropertyName = “ItemName”, .HeaderText = “品名”
})
.Columns.Add(New DataGridViewTextBoxColumn With {
.Name = “OrderDate”, .DataPropertyName = “OrderDate”, .HeaderText = “注文日”,
.ValueType = GetType(DateTime) ‘ ★重要: 基盤となる型を明示
})
.Columns.Add(New DataGridViewTextBoxColumn With {
.Name = “Amount”, .DataPropertyName = “Amount”, .HeaderText = “金額”,
.ValueType = GetType(Decimal) ‘ ★重要: 基盤となる型を明示
})

‘ 列の自動生成をオフにした場合は、手動で列を追加した後にDataSourceを設定する方が良い場合もある
‘ 今回は自動生成後にカスタム列を設定する形だが、設計によって適宜調整すること

‘ ヘッダーのスタイル調整
For Each col As DataGridViewColumn In .Columns
col.HeaderCell.Style.Alignment = DataGridViewContentAlignment.MiddleCenter
If col.ValueType Is GetType(Decimal) Then
col.DefaultCellStyle.Alignment = DataGridViewContentAlignment.MiddleRight ‘ 金額は右寄せ
ElseIf col.ValueType Is GetType(DateTime) Then
col.DefaultCellStyle.Alignment = DataGridViewContentAlignment.MiddleCenter ‘ 日付は中央寄せ
End If
Next
End With

‘ イベントハンドラの登録
AddHandler DataGridView1.CellFormatting, AddressOf DataGridView1_CellFormatting
AddHandler DataGridView1.CellParsing, AddressOf DataGridView1_CellParsing
AddHandler DataGridView1.DataError, AddressOf DataGridView1_DataError ‘ エラーハンドリングも重要
End Sub

【チーフアーキテクトの教え】: `AutoGenerateColumns = False`は、大規模なデータソースや複雑なUIを持つシステムでは必須の選択だ。列の表示順序、ヘッダーテキスト、`ValueType`、`ReadOnly`属性などを開発者が完全に制御できる。`ValueType`を明示することで、`DataGridView`は型の変換をより賢く行うことができる。

4.2. 日付型カラムの制御 (`OrderDate`列)

CellFormatting for DateTime (表示)

セルの編集中はプレーンな日付（例: “YYYY/MM/DD”）を表示し、非編集中はカスタムフォーマット（例: “YYYY年MM月DD日 (曜日)”）を表示する。`Nothing`や`DBNull.Value`の場合は空欄とする。

.net
‘ DataGridView1_CellFormattingイベントハンドラ (Form1クラス内)
Private Sub DataGridView1_CellFormatting(sender As Object, e As DataGridViewCellFormattingEventArgs)
‘ 処理対象の列か、そして有効な行インデックスかを確認
If e.ColumnIndex = DataGridView1.Columns(“OrderDate”).Index AndAlso e.RowIndex >= 0 Then
‘ セルが編集中かどうかで表示を分ける
If DataGridView1.IsCurrentCellInEditMode Then
‘ 編集中はプレーンな形式 (入力しやすいように)
If e.Value IsNot Nothing AndAlso TypeOf e.Value Is DateTime Then
Dim dtValue As DateTime = CDate(e.Value)
e.Value = dtValue.ToString(“yyyy/MM/dd”) ‘ 例: 2023/10/26
e.FormattingApplied = True
Else
e.Value = String.Empty ‘ Nullの場合は空欄
e.FormattingApplied = True
End If
Else
‘ 非編集中はカスタムフォーマット
If e.Value IsNot Nothing AndAlso TypeOf e.Value Is DateTime Then
Dim dtValue As DateTime = CDate(e.Value)
‘ 和暦と曜日を含む表示
e.Value = dtValue.ToString(“ggyy年M月d日 (ddd)”, New System.Globalization.CultureInfo(“ja-JP”))
‘ または、西暦と曜日を含む表示
‘ e.Value = dtValue.ToString(“yyyy年MM月dd日 (ddd)”)
e.FormattingApplied = True
Else
e.Value = String.Empty ‘ Nullの場合は空欄
e.FormattingApplied = True
End If
End If
ElseIf e.ColumnIndex = DataGridView1.Columns(“Amount”).Index AndAlso e.RowIndex >= 0 Then
‘ 金額列のフォーマットは次のセクションで記述
‘ … (後述の金額フォーマット処理をここに記述)
End If

‘ 他の列の処理が必要な場合はここに追加
End Sub

【チーフアーキテクトの教え】: `DataGridView.IsCurrentCellInEditMode`の判定は非常に重要だ。ユーザーはフォーマットされた文字列を入力したいわけではない。編集時には、最もシンプルな入力形式を提供することが、ユーザーエクスペリエンスを向上させる秘訣だ。`e.FormattingApplied = True`を忘れずに設定し、デフォルトのフォーマット処理をスキップさせる。

CellParsing for DateTime (入力とバリデーション)

ユーザーの入力文字列を`DateTime`型に変換し、不正な入力は弾く。複数の入力形式に対応できるよう、ヘルパー関数を導入する。

.net
‘ ヘルパークラスまたはモジュールに定義することを推奨 (例: DateParsingHelper.vb)
Public Module DateParsingHelper
”’

”’ 複数の書式に対応する日付文字列解析ヘルパー。
”’

”’ 解析対象の文字列。 ”’ 解析に成功した場合のDateTime値。 ”’ 解析に成功した場合はTrue、それ以外はFalse。
Public Function TryParseFlexibleDate(ByVal s As String, ByRef result As DateTime?) As Boolean
If String.IsNullOrWhiteSpace(s) Then
result = Nothing
Return True ‘ 空文字列はNullを意味し、成功とみなす
End If

Dim dt As DateTime
‘ 許容する日付書式を定義 (優先順位順)
Dim formats As String() = {
“yyyy/MM/dd”, “yyyy-MM-dd”, “yyyyMMdd”,
“M/d”, “M/dd”, “MM/d”, “MM/dd”, ‘ 年を自動補完 (CurrentCultureの年)
“ggyy年M月d日”, “ggyy/M/d”, ‘ 和暦対応
“yy/MM/dd” ‘ 西暦下2桁
}

‘ TryParseExactで厳密にパースを試みる
If DateTime.TryParseExact(s, formats, System.Globalization.CultureInfo.CurrentCulture,
System.Globalization.DateTimeStyles.AllowInnerWhite |
System.Globalization.DateTimeStyles.AssumeLocal, dt) Then
result = dt
Return True
End If

‘ その他の一般的な書式でパースを試みる (TryParseはより柔軟だが意図しないパースもありうる)
If DateTime.TryParse(s, System.Globalization.CultureInfo.CurrentCulture,
System.Globalization.DateTimeStyles.AllowInnerWhite |
System.Globalization.DateTimeStyles.AssumeLocal, dt) Then
result = dt
Return True
End If

result = Nothing
Return False ‘ どの書式にも一致しない
End Function
End Module

‘ DataGridView1_CellParsingイベントハンドラ (Form1クラス内)
Private Sub DataGridView1_CellParsing(sender As Object, e As DataGridViewCellParsingEventArgs)
‘ 処理対象の列か、そして期待する型かを確認
If e.ColumnIndex = DataGridView1.Columns(“OrderDate”).Index AndAlso e.DesiredType Is GetType(DateTime) Then
Dim inputString As String = e.Value?.ToString()

Dim parsedDate As DateTime?
If DateParsingHelper.TryParseFlexibleDate(inputString, parsedDate) Then
e.Value = parsedDate ‘ パース成功。NothingまたはDateTime値をセット
e.ParsingApplied = True
‘ エラーテキストをクリア (以前のエラーが残っている可能性があるので)
DataGridView1.Rows(e.RowIndex).Cells(e.ColumnIndex).ErrorText = String.Empty
Else
‘ パース失敗
e.ParsingApplied = False ‘ デフォルトのパース処理を続行させない
‘ エラーテキストを設定してユーザーにフィードバック
DataGridView1.Rows(e.RowIndex).Cells(e.ColumnIndex).ErrorText = “日付として認識できません。例: YYYY/MM/DD, MM/DD”
‘ 必要に応じて、元の値に戻すなどの処理も検討
‘ e.Value = DataGridView1.Rows(e.RowIndex).Cells(e.ColumnIndex).Value ‘ 元の値に戻す例
End If
ElseIf e.ColumnIndex = DataGridView1.Columns(“Amount”).Index AndAlso e.DesiredType Is GetType(Decimal) Then
‘ 金額列のパースは次のセクションで記述
‘ … (後述の金額パース処理をここに記述)
End If

‘ 他の列の処理が必要な場合はここに追加
End Sub

【チーフアーキテクトの教え】: `TryParseFlexibleDate`のようなヘルパー関数を導入することで、パースロジックが`DataGridView`イベントハンドラから分離され、再利用性とテスト容易性が格段に向上する。`DataGridViewCell.ErrorText`は、ユーザーにエラーを視覚的に伝えるための非常に有効な手段だ。`e.Value = parsedDate`で`Nothing`をセットできるのは、`ValueType`が`DateTime`であっても、データバインディングが`DBNull.Value`への変換を適切に行ってくれるためだ。

4.3. 金額型カラムの制御 (`Amount`列)

CellFormatting for Decimal (表示)

セルの編集中はカンマなしの数値（例: “1234567.89”）を表示し、非編集中は通貨記号とカンマ区切り（例: “¥1,234,567″）を表示する。`Nothing`や`DBNull.Value`の場合は空欄とする。

.net
‘ DataGridView1_CellFormattingイベントハンドラ (上記の日付処理のElseIfブロックに追記)
‘ Private Sub DataGridView1_CellFormatting(sender As Object, e As DataGridViewCellFormattingEventArgs)
‘ … 日付処理の後に記述 …

ElseIf e.ColumnIndex = DataGridView1.Columns(“Amount”).Index AndAlso e.RowIndex >= 0 Then
‘ セルが編集中かどうかで表示を分ける
If DataGridView1.IsCurrentCellInEditMode Then
‘ 編集中はプレーンな形式 (カンマ、通貨記号なし)
If e.Value IsNot Nothing AndAlso TypeOf e.Value Is Decimal Then
Dim decValue As Decimal = CDec(e.Value)
e.Value = decValue.ToString(“F2”) ‘ 例: 1234567.89 (小数第2位まで)
e.FormattingApplied = True
Else
e.Value = String.Empty ‘ Nullの場合は空欄
e.FormattingApplied = True
End If
Else
‘ 非編集中はカスタムフォーマット (通貨記号、カンマ区切り)
If e.Value IsNot Nothing AndAlso TypeOf e.Value Is Decimal Then
Dim decValue As Decimal = CDec(e.Value)
‘ 通貨形式で表示。Cultureによって記号や小数点の扱いが変わる
e.Value = decValue.ToString(“C”) ‘ 例: ¥1,234,567.89
‘ または、Cultureを明示して厳密に制御
‘ e.Value = decValue.ToString(“C”, New System.Globalization.CultureInfo(“ja-JP”))
e.FormattingApplied = True
Else
e.Value = String.Empty ‘ Nullの場合は空欄
e.FormattingApplied = True
End If
End If
End If
‘ End Sub

【チーフアーキテクトの教え】: `ToString(“F2”)`は固定小数点数形式で、編集時には最もシンプルで入力しやすい形を提供できる。`ToString(“C”)`は現在のカルチャの通貨形式で表示されるため、国際化を考慮する場合は`CultureInfo`を明示的に指定することも検討すべきだ。

CellParsing for Decimal (入力とバリデーション)

ユーザーの入力文字列を`Decimal`型に変換し、不正な入力は弾く。カンマや通貨記号があってもパースできるようにする。

.net
‘ ヘルパークラスまたはモジュールに定義することを推奨 (例: NumberParsingHelper.vb)
Public Module NumberParsingHelper
”’

”’ 複数の書式に対応する金額文字列解析ヘルパー。
”’

”’ 解析対象の文字列。 ”’ 解析に成功した場合のDecimal値。 ”’ 解析に成功した場合はTrue、それ以外はFalse。
Public Function TryParseFlexibleDecimal(ByVal s As String, ByRef result As Decimal?) As Boolean
If String.IsNullOrWhiteSpace(s) Then
result = Nothing
Return True ‘ 空文字列はNullを意味し、成功とみなす
End If

Dim dec As Decimal
‘ NumberStyles.Any: 数値、通貨記号、カンマ、小数点、符号、括弧などを許容
If Decimal.TryParse(s, System.Globalization.NumberStyles.Any,
System.Globalization.CultureInfo.CurrentCulture, dec) Then
result = dec
Return True
End If

result = Nothing
Return False ‘ パース失敗
End Function
End Module

‘ DataGridView1_CellParsingイベントハンドラ (上記の日付処理のElseIfブロックに追記)
‘ Private Sub DataGridView1_CellParsing(sender As Object, e As DataGridViewCellParsingEventArgs)
‘ … 日付処理の後に記述 …

ElseIf e.ColumnIndex = DataGridView1.Columns(“Amount”).Index AndAlso e.DesiredType Is GetType(Decimal) Then
Dim inputString As String = e.Value?.ToString()

Dim parsedDecimal As Decimal?
If NumberParsingHelper.TryParseFlexibleDecimal(inputString, parsedDecimal) Then
‘ ここで金額のビジネスルールバリデーションも行うと良い
‘ 例: 金額が負数でないか、上限値を超えていないかなど
If parsedDecimal.HasValue AndAlso parsedDecimal.Value < 0D Then e.ParsingApplied = False DataGridView1.Rows(e.RowIndex).Cells(e.ColumnIndex).ErrorText = "金額は0以上で入力してください。" Return ' 以降の処理をスキップ End If e.Value = parsedDecimal ' パース成功。NothingまたはDecimal値をセット e.ParsingApplied = True DataGridView1.Rows(e.RowIndex).Cells(e.ColumnIndex).ErrorText = String.Empty Else ' パース失敗 e.ParsingApplied = False DataGridView1.Rows(e.RowIndex).Cells(e.ColumnIndex).ErrorText = "金額として認識できません。例: 12345, ¥1,234" End If End If ' End Sub 【チーフアーキテクトの教え】: `NumberStyles.Any`は非常に強力だが、同時にリスクも伴う。特定の形式のみを許容したい場合は、`NumberStyles.Currency`や`NumberStyles.Number`などを組み合わせて、より厳密に制御すべきだ。
また、パースに成功した後のビジネスルールバリデーションも重要だ。例えば、「金額は0以上でなければならない」といったルールは、ここで適用するのが自然だ。

4.4. 総合的なエラーハンドリング (`DataGridView.DataError`イベント)

`CellParsing`で`e.ParsingApplied = False`とした場合、`DataGridView`は`DataError`イベントを発火させる。このイベントを適切にハンドリングすることで、ユーザーに不快なデフォルトのエラーダイアログが表示されるのを防ぎ、よりユーザーフレンドリーなエラー通知を実現できる。

.net
‘ DataGridView1_DataErrorイベントハンドラ (Form1クラス内)
Private Sub DataGridView1_DataError(sender As Object, e As DataGridViewDataErrorEventArgs) Handles DataGridView1.DataError
‘ CellParsingイベントでエラーテキストを設定済みであれば、ここでは何もしない
‘ または、より詳細なログ記録を行う
Console.WriteLine($”DataGridView DataError: ColumnIndex={e.Column.Index}, RowIndex={e.Row.Index}, Exception={e.Exception.Message}”)

‘ デフォルトのエラーダイアログを表示しないようにする
e.ThrowException = False
‘ エラーが発生したセルを視覚的に強調するなどの処理も可能
‘ DataGridView1.Rows(e.RowIndex).Cells(e.ColumnIndex).Style.BackColor = Color.LightCoral
‘ DataGridView1.Rows(e.RowIndex).Cells(e.ColumnIndex).ToolTipText = e.Exception.Message
End Sub

【チーフアーキテクトの教え】: `e.ThrowException = False`は、`DataGridView`のデフォルトのエラーダイアログが表示されるのを防ぐ上で極めて重要だ。ユーザーは、システム内部の例外メッセージではなく、彼らが理解できる言葉でエラーを伝えられるべきだ。`CellParsing`で`ErrorText`を設定済みであれば、`DataError`では主にログ記録や、さらに上位のエラー通知（ステータスバー表示など）を行うと良い。

第5章：データベース/ファイル連携と堅牢性

ここまでの実装で、`DataGridView`上でのデータ入力と表示はかなり堅牢になった。しかし、最終的にデータはデータベースやファイルに保存される。ここでの注意点を述べる。

5.1. データバインディング時の型の整合性

`DataGridViewColumn.ValueType`とデータソースの実際の列の型（`DataTable`なら`DataColumn.DataType`、`List(Of T)`ならプロパティの型）は、極力一致させるべきだ。これにより、`DataGridView`とデータソース間の型変換がスムーズに行われ、意図しないエラーを防ぐことができる。

例えば、データベースの`DATETIME`型に対応する`DataTable`の列は`GetType(DateTime)`、`DECIMAL`型は`GetType(Decimal)`とする。`NULL`を許容する列は、`DateTime?` (Nullable(Of DateTime)) や `Decimal?` (Nullable(Of Decimal)) といったNullable型を使用し、`DBNull.Value`との変換を適切に行う必要がある。

5.2. 保存時の最終バリデーション

`CellParsing`で入力値のバリデーションは行われるが、これはあくまで「セル単位」でのバリデーションだ。複数セルにまたがる複合的なビジネスルール（例: 「開始日は終了日より前でなければならない」）や、データがデータベースに保存される直前に行うべき最終的なバリデーションは、別途実装する必要がある。

これは、`BindingSource.EndEdit()`や、`DataTable.RowChanging` / `RowValidating`イベント、または`Save`ボタンクリック時のイベントハンドラなどで実装するのが一般的だ。エラーがあれば、保存処理を中断し、ユーザーに明確なフィードバックを与える。

5.3. ユニットテストの重要性

今回作成した`TryParseFlexibleDate`や`TryParseFlexibleDecimal`のようなヘルパー関数は、UIから分離された純粋なロジックであるため、ユニットテストの対象として最適だ。

例えば、`NUnit`や`xUnit`などのフレームワークを使用して、以下のようなテストケースを網羅的に記述すべきだ。

有効な入力文字列が正しくパースされるか（複数のフォーマット）。
無効な入力文字列が正しく拒否されるか。
空文字列が`Nothing`として正しくパースされるか。
境界値（最小値、最大値）が正しく扱われるか。

これにより、予期せぬ入力に対するロバストネス（堅牢性）を保証し、将来の改修時のデグレードを防ぐことができる。

第6章：よくある落とし穴と回避策

最後に、私がこれまで見てきた中で、開発者が`DataGridView`のこれらのイベントで陥りがちな落とし穴とその回避策を共有しておこう。

6.1. CellFormattingでe.Valueを直接変更してしまう

これは最もよくあるミスだ。
誤った例: `e.Value = CDate(e.Value).AddDays(1)`
解説: `CellFormatting`は「表示」のためのイベントであり、基盤となるデータソースの値を変更してはならない。上記のようなコードは、表示のたびにデータソースの値が変更されてしまうという、恐ろしいバグを引き起こす。
回避策: `e.Value`は読み取り専用のつもりで扱い、表示したい値を別の変数で生成し、それを`e.Value`に代入する。

6.2. CellParsingでFormatException以外の例外を捕捉しきれない

`TryParse`パターンを使わず、`DateTime.Parse`や`Decimal.Parse`を直接呼び出し、`Try…Catch FormatException`だけで済ませるケース。
誤った例:
.net
Try
e.Value = DateTime.Parse(e.Value.ToString())
e.ParsingApplied = True
Catch ex As FormatException
e.ParsingApplied = False
‘ エラーメッセージ
End Try

解説: ユーザーが入力するデータは、`FormatException`だけでなく、`OverflowException`（数値が型の上限を超えた場合）や、その他予期せぬ例外を引き起こす可能性がある。また、`Parse`メソッドは`null`や空文字列に対して`ArgumentNullException`を投げることもある。
回避策: `TryParse`パターンを徹底する。これが、例外に頼らずに安全に型変換を行うための最善の手法だ。そして、`TryParse`が対応しきれない複雑なビジネスルールについては、別途ロジックでバリデーションを行う。

6.3. IME入力と数字・記号入力の混在時の考慮

日本語入力（IME）が有効な状態で、全角数字や全角記号が入力される可能性がある。
解説: `TryParse`系メソッドは、カルチャ設定に依存するものの、全角数字や特定の全角記号（例: 「，」）もある程度はパースできる。しかし、ユーザーの入力意図と異なる結果になることもある。
回避策:

入力欄（`DataGridViewTextBoxEditingControl`）に対して、IMEモードを制御する（例: 半角英数モードにする）。これは`EditingControlShowing`イベントで`e.Control`をキャストして設定できる。
`CellParsing`内で、必要に応じて全角文字を半角文字に変換する前処理を行う（例: `Strings.StrConv(inputString, VbStrConv.Narrow)`）。ただし、これはユーザーの入力が意図せず変更される可能性があるため、慎重に適用すること。

6.4. コピペ入力時の挙動

Excelなどから複数のセルをコピーして`DataGridView`に貼り付けた際の挙動も考慮すべきだ。
解説: `DataGridView`は、デフォルトでタブ区切りテキストの貼り付けをサポートしている。この際、`CellParsing`イベントが各セルに対して順次発火する。
回避策: 今回実装した`CellParsing`ロジックは、個々のセル入力に対応しているため、基本的にはコピペ時にも機能する。ただし、大量のデータ貼り付けの場合、`CellParsing`の処理が重いとパフォーマンスに影響が出る可能性がある。その場合は、`DataGridView.ClipboardCopyMode`や`DataGridView.AllowUserToAddRows`などのプロパティと組み合わせて、貼り付け処理全体のパフォーマンスとエラーハンドリングを最適化する必要がある。

結論：極限の知見を血肉とし、真の業務効率化ツールを創り出せ

諸君、`DataGridView`の`CellFormatting`と`CellParsing`イベントは、単なる表示と入力の変換にとどまらない。これらは、ユーザーエクスペリエンス、データの整合性、システムのパフォーマンス、そして保守性の全てを左右する、極めて重要な要素だ。

今日、私が伝授した「極限の知見」――データモデルと表示ロジックの徹底分離、カスタムフォーマッタ/パーサの導入、堅牢なバリデーションとユーザーフィードバック、そしてパフォーマンスへの配慮――これらを血肉とし、諸君の業務システム開発に活かしてほしい。

安易なコードは、その場しのぎにしかならない。しかし、これらの原則に基づいた設計は、長期にわたって安定稼働し、ユーザーに真の価値を提供する、堅牢で保守性の高いシステムを構築するための揺るぎない基盤となるだろう。

諸君の魂を込めたシステムが、世の業務を革新することを期待している。健闘を祈る。