DataGridViewのSelectionChangedイベントにおける移動元・移動先の行インデックスの取得

Question

現在Windows Formsで、画面左側にDataGridView、右側にテキストボックスやチェックボックスなどを表示するようなシステムの開発をしています。
その中で入力された内容をデータベースに保存、行が切り替わるときにその選択した行の内容をテキストボックスなどに反映する、という処理を行う必要があリます。
しかし、SelectionChangedイベントではCurrentRowを用いたり下記のようなコーディングをしても移動後の行インデックスを取得してくるようで、移動元のデータを更新する処理をうまく書けずにいます。
どうにかして同一イベント内で移動元と移動先の行インデックスを処理する方法はないものでしょうか？

（どこかで引数eの型をDataGridViewCellEventArgsにしてe.RowIndexとすれば移動元のインデックスを取得できる旨の文章を見た気がするのですが、単純に型を変えただけではInvalidCastExceptionが発生しデバッグできませんでした）

Private Sub dataGridView1_SelectionChanged(sender As Object, e As EventArgs) Handles dataGridView1.SelectionChanged
    For Each row As DataGridViewRow In dataGridView1.SelectedRow
        Dim index As Integer = dataGridView1.Rows(row.Index).Index
    Next
    'データ保存・更新を行う関数を呼んだ後、新しい行の情報を表示する関数を呼び出します
End Sub

---20190106追記---
大事なことを書き忘れていましたが、現在更新周りの処理をRowLeaveイベント内で行っています。
このイベントがテキストボックスなどにフォーカスが移った際にも発生してしまうので、一度の処理で何度も更新処理が行われバグの一因になっているため、できればイベントを分けないほうが良いのではと思い質問しました。

Comments

[Zuishin]

普通このような処理はインデックスを使わず BindingSource を使います。

Answer 1

選択されたときにそのセルのRowIndexを覚えておいて、処理すればいいんじゃないですか？
もしくは、DataGridView.RowEnterイベントで、CurrentRowプロパティとDataGridViewCellEventArgs.RowIndexプロパティを利用するとか

Comments

[musix55]

だいぶ返信が遅くなりました。
やはりそのやり方がいいのでしょうかね…
一応試みてはみたのですが、いろいろなイベントや関数が絡み合っていることもあって自分ではうまくインデックスを取得できませんでした。
また大事なことを書き忘れていましたが、現在更新周りの処理をRowLeaveイベント内で行っています。
このイベントがテキストボックスなどにフォーカスが移った際にも発生してしまうので、一度の処理で何度も更新処理が行われバグの一因になっているため、できればイベントを分けないほうが良いのではと思い質問しました。
後出しになり申し訳ありません。

[YAmaGNZ]

動きに関してなのですが
１．DataGridViewの行を選択すると、右側の編集領域にその行のデータを表示する。
２．編集領域でデータを変更する
３．DataGridViewで別の行を選択する
・このタイミングで前の行のデータを編集領域のデータで更新
・選択した行を編集領域に表示する
このような動きを想定されているのでしょうか？

この場合、編集領域にてデータを変更し、選択行を変更しない場合はデータが更新されないことになりますがよろしいのですか？
また、上記の動きで合っているのであれば、編集領域でのデータ変更をキャンセルする方法もなさそうですがいいのでしょうか？

どちらにしろ、更新タイミングをどうするのかUIの変更（更新ボタンの追加等）も視野に入れてしっかり考えた方がいいような気がします。
RowLeaveイベントで行うにしても、表示したデータから変更がない場合は更新しないなどの処理を入れれば無駄な更新はなくなりそうですし、そういうことも含めて整理されてみてはどうでしょうか？

[musix55]

・動きに関して → ご指摘の通りです。
・行を変更しない場合
→例えば最終行からは行が移らないといった話ですよね？これについては、全員分の内容確認・入力が終わった時点でユーザーに確定ボタンを押してもらい、その中で最後に選択した行の編集内容を更新する関数を走らせているので、理屈上は更新の漏れはないはずです。
データ変更をキャンセルできないのはその通りなのですが、現時点では今のやり方でそのまま進める予定です。

書き始めてからだいぶ時間が経っていることもあって、処理のつながりが見えにくくなっていると自分でも思います。おっしゃる通り少し時間をとって整理してみようと思います。
返信ありがとうございました。

[YAmaGNZ]

他にどのようなイベントでどのような処理を行っているのか分からないので明確な回答は難しいです。
とりあえず、イベントハンドラを作成し、ログを出力するだけにしておいて、どのイベントがどのタイミングで発生するか確認し、データの更新タイミング、データの表示タイミングを決定してください。
回答に書いた通り、編集対象行を覚えておくか、RowEnterイベントで処理するのが楽そうに思えます。