ICommand
はインターフェースなので、本質的に抽象的です。直接使用することはできません。それを実装するものが必要です。(例RelayCommand
)
WPF は : の組み込み実装を提供しICommand
ますRoutedCommand
。(および関連する派生型RoutedUICommand
.) ただし、これらの型は、説明したものと一致しない非常に特殊なシナリオ向けに設計されています。(UI ツリーの構造を使用して、コマンドを処理するものを決定します。これは、通常、コントロールによって直接提供される共通コマンドの複数の異なる実装がある場合にのみ適切です。たとえば、TextBox は、切り取り、コピー、貼り付けの実装方法を知っています。などで、コマンドを処理するフォーカスのある TextBox が必要です。)
したがって、実際には「通常の」ICommand
実装はありません。また、おそらく検証ルールを使用したくないでしょう...
検証ルールはかなり制限されており、説明したシナリオをサポートすることは非常に困難です。これらには 2 つの制限があります。
- それらは、コンテキストを必要とせずに適用できる完全に自己完結型の検証ルールにのみ適しています。(例: 「この文字列は 10 進数ですか?」)
- メカニズム全体にコンテキストの概念がないため、それらを他のものと結び付けるのは困難です。
その2番目のものは、あなたがやりたいことをするのを難しくします。これが、Microsoft がより優れたメカニズムを導入した理由であると思われます。ほとんどの検証シナリオでは、ValidationRule を使用せず、代わりにデータ ソースに IDataErrorInfo を実装します。
原則として、有効かどうかを判断するのはデータ ソース オブジェクトです。また、データ ソース オブジェクトは、任意のコマンドの有効性を変更することもできます。これが、アイテムが無効な場合に OkCommand オブジェクトを無効にする方法です。
また、WPF は、このシナリオに適した ICommand の単純な組み込み実装を提供していないため、RelayCommand
. これは、WPF には実際には組み込みの「通常の」コマンドがないという事実への対応です。ファンキーなルーティング コマンドしかありません。