Binding がソースを更新する前に、ユーザーがテキスト ボックス内のテキストを更新した時期を判断するにはどうすればよいですか?
TextBox または Binding のいずれかで「IsDirty」プロパティを見つけることを期待していました...
私の問題は、[キャンセル] ボタンの Enabled プロパティが ViewModel の IsDirty プロパティにバインドされており、フォーカスがテキスト ボックスから移動するまで無効になっていることです。
「IsDirty」は ViewModel.IsDirty || として定義する必要があります。TextBox.IsDirty
WPF は、高品質のアプリケーションでユーザーが期待する典型的な IsDirty 動作をサポートできません。
この問題は、Binder クラスの奇妙な設計に起因します。
さらに、WPF アーキテクチャは、デフォルトの Binder 実装を使用するようにハードコードされているため、それを置き換えるのは大変な作業であり、無限の WPF 設計上の欠陥を回避するには多くの「汚いトリック」が必要です。
この制限を回避する最も簡単な方法は、すべての値変換ロジックをビュー モデルに移動し、UpdateSourceTrigger=PropertyChanged を使用して、独自の IsDirty および IsInvalid ロジックとフラグを実装することです。
このアプローチは、Caliburn.Micro でもうまく機能します。
まず、キャンセルが無効になっているのはなぜですか? 常に有効にする必要があります。それ以外の動作は奇妙です。ユーザーは何もしていなくてもキャンセルできるはずです。
次に、Commandsビューモデルの状態に基づいて実行できるかどうかを判断できるように使用します。ビューモデルがコマンドの実装も提供する場合、実装は簡単です。
それに関する記事やチュートリアルを読むことをお勧めします。インターフェイスの Google ICommand。
そして、あなたの質問に答えるために。バインディングを使用していると仮定すると、INotifyPropertyChangingインターフェイスを使用して、値がいつ変更されるかを判断できます。次に、現在の値をバックアップ フィールドなどに保存できます。
編集 - 「彼にデータを失わせる」について
確かに有効な戦略です。入力を永続化する前に検証する必要がある 5 つの入力コントロールなど、より大きな入力ダイアログを考えてみてください。あなたの議論によれば、データは非常に重要であると思います。さらに、あなたは自分のデータをダイアログにハッキングし始めました。入力コントロール 3 で、'ALT + F4' を押すことにしました。
まず、ユーザーがキーを押した理由を自問してください。私見、彼は自分のデータに何が起こっているか気にしません。「ALT + F4」が堅牢であることの単なる例である場合。気にしないで。絶対的な堅牢性は、非常に高価でなければ実装できないと思います。
次に、アプリケーションの再起動後の一貫性と有効性に関して、未定義の状態から開始しないように、データを破棄する必要があります。ユーザーが入力を開始したエンティティは、この状態では有効ではないことに注意してください。どちらの状態も、プロパティの値はそうではありません。
したがって、IMHO のはるかに優れた戦略は、クリーンで定義された状態で再起動することです。これにより、ユーザーはアプリケーションでやりたいことを何でも続行できます。
なぜこの戦略が優れているのですか？まあ、実装するのははるかに簡単です。そしてもっと重要な議論は、奇妙な状態のためにユーザーが道に迷うことはないということです。