問題タブ [routed-commands]

WPFのコントロール間の通信を可能にする正しいメカニズムは何でしょうか。私の目標は、従来のイベントを使用せず、手動でそれらを接続する必要があることです。ルーティングされたコマンドのデフォルトの動作（トンネリング、バブリング）は正しい方向に沿っているように見えますが、何かが足りないと思います。

ルーティングされたイベントは、WPFによって提供される新しいインフラストラクチャであり、イベントがビジュアルツリーを下ってターゲット要素にトンネリングしたり、ルート要素にバブルアップしたりできるようにします。イベントが発生すると、途中で遭遇したそのイベントにサブスクライブされた要素で、そのイベントのハンドラーを呼び出すビジュアルツリーを上下に「移動」します。 このツリートラバーサルは、ビジュアルツリー全体をカバーするのではなく、祖先要素のみをカバーすることに注意してください。

これは、このWPF記事からのものです

記事の画像を使用して、「Immediate Element＃1」でイベントを開始（発生）させてから、「Immediate Element＃2」でそのイベントを処理するようにします。「ルート要素」にコードを入れずにこれを実現したいと思います。

基本的に、アプリのどこからでもイベント（保存、ステータスの更新、選択の変更など）を発生させ、2つのパーティがお互いについて何も知らない状態で別の場所で処理するようにします。これは可能ですか？

私はデータベイディングが答えだとは思わない。ルーティングされたイベント/コマンドは、ソース管理のブランチ内だけでなく、ツリー全体で設計されているため、使用したいと思います。ルーティングされたイベント/コマンドを使用して実行できない可能性があり、データバインディングがその答えです。わからない...

何か案は？

MV-VM を使用して WPF に RoutedCommands を実装しようとした人は誰でも、間違いなく問題に遭遇しています。コマンド (UI 以外のコマンド) は ViewModel に実装する必要があります。たとえば、CustomerViewModel を保存する必要がある場合は、CustomerViewModel に直接コマンドとして実装します。ただし、ウィンドウをポップアップしてユーザーのアドレスを表示したい場合は、UI 固有の関数であるため、ShowCustomerAddress コマンドをビューに直接実装します。

ビューモデルでコマンド バインディングを定義し、それらをビューで使用するにはどうすればよいですか?

私が理解していることから、コマンドパターンの目標は、UIの相互作用をアプリケーションロジックから分離するのを助けることです。適切に実装されたコマンドを使用して、[印刷]メニュー項目をクリックすると、次のような一連の対話が発生する可能性があります。

これにより、UIをアプリケーションロジックから分離することができます。

私はWPFコマンドを見てきましたが、ほとんどの場合、このパターンがどのように実装されているかがわかります。ただし、ある程度、コマンドパターンが複雑になり、UIをアプリケーションロジックから分離することを思いとどまらせるような方法で実装できたように感じます。

たとえば、テキストボックスにテキストを貼り付けるボタンがあるこの単純なWPFウィンドウについて考えてみます。

コードビハインドは次のとおりです。

コマンドから何を得ましたか？コマンドバインディングイベントハンドラーのコードをボタンのイベントに簡単に配置できたように思えますClick。もちろん、複数のUI要素を[貼り付け]コマンドに関連付けることができ、1つのイベントハンドラーを使用するだけで済みますが、複数の異なるテキストボックスに貼り付けたい場合はどうすればよいですか？イベントハンドラロジックをより複雑にするか、より多くのイベントハンドラを作成する必要があります。だから今、私はこれを持っているように感じます：

ここで何が欠けていますか？それは私には間接的な余分な層のように見えます。

マスター/ディテール UI パターンを使用する単純な WPF プログラムがあります。詳細には、マスター ペインでコレクションの現在選択されている項目が表示されます。私はMVVMを使用しています。各XAMLページは、DataContextとして設定されたViewModelオブジェクトによって支えられています。

ここで、マスター ペインに [削除] ボタンを追加して、アイテムのマスター リストから削除したいと考えています。ただし、現在選択されている項目のビューモデル オブジェクトをボタン CommandParameter としてルーティングされたコマンド ハンドラー コードに渡す方法がわかりません。

ご指摘ありがとうございます。

マイク

UI のさまざまな場所からアクセスできる単一の RoutedUICommand があります。グローバルキーボードショートカット、メニュー、ContextMenu、またはボタンなど。RoutedUICommand.CanExecute および RoutedUICommand.Execute メソッドで実行されるコードは、使用された UI 要素によって異なります。この差別化をどのように達成できますか。(Can)ExecutedRoutedEventArgs.Source または OrigianlSource を使用できると考えていましたが、ソースは常に同じです。これは、ルートのメイン ウィンドウです。これは通常どのように達成されますか？私は何が間違っているのでしょうか？

私は今日、WPF プログラムでロジックを処理する方法の設計パターンを選択することについて誰かと話し、SO コミュニティが決定を容易にするためのさらなるアドバイスを提供してくれることを望んでいました。コマンドを支持する要因は、不便さを上回っていますか?

3 つのアプローチのうち最初の 2 つのUML ダイアグラムとともに完全なサンプルを用意しました。

1. ボタンとメニューで Click イベント ハンドラーを使用します。
2. XAML にバインドされたコマンドを使用します。
3. コードにバインドされたコマンドを使用し、純粋な GUI レイアウトとスタイリングのために XAML を保持します。

彼が受講した入門コースや多くの書籍では、ロジックを UI オブジェクトに接続する自然な方法として単純な Click イベント ハンドラーが示されています。

彼は、コマンドを使用するために必要なオーバーヘッドの量に少し驚いていました。両方のコマンドがコード ビハインド ファイルで作成されています。

次に、コマンドを識別してバインドする必要がある冗長な方法を使用して、XAML 内にさらに多くのコードを記述します。

私は (まだ) WPF の専門家であるとは言えないので、実際よりも複雑に描いているかもしれませんが、上記よりもはるかに単純化することはできないのではないかと疑っています。

編集：

DelegateCommand、RoutedCommand、および Eventの興味深い3 方向の比較を見つけました。

より良い説明、私は願っています：

• 3 つのボタンがあるツールバーがあり、3 つすべてがコマンド (CommandParameter を含む) にバインドされています。
• このツールバーは複数の画面で使用されます
• ツールバーの xaml は、これらすべての画面でまったく同じです

ツールバー インスタンスを削除し、3 つのコマンドを提供するユーザー コントロールに置き換えて、各画面でバインディングを保持できるようにします。ツールバーの機能は後で変更する予定ですが、外部プログラミング インターフェイス (つまり、3 つのコマンド) は同じです。

そう：

• ユーザー コントロールを作成し、コマンドごとに 3 セットの依存関係プロパティ (OneCommand、OneCommandParameter、OneCommandTarget) を作成して、これらをバインドに使用できるようにしました。
• ツールバーの xaml をユーザー コントロールの xaml 内に移動しました。
• 組み込みのユーザー コントロール プロパティにバインドするように、ツールバー ボタンのバインドを変更しました。
• 各画面 (実際には最初の画面のみ) で、元のツールバーをユーザー コントロールに置き換え、新しいプロパティを正しいコマンドにバインドしました。

コントロールは表示されますが、ボタンは機能しません。それはそれについてです。

--

元の説明 - あまり明確ではありません:

多数のボタンをカプセル化する WPF ユーザー コントロールがあります。以前は、コントロールは多数のボタンを備えたツールバーでしたが、多数の画面でまったく同じ機能が必要なため、ツールバーをカスタム コントロールにリファクタリングしました。

ただし、元のボタンのコマンド バインドを保持したいと思います。

• ユーザー コントロールに 3 セットの依存関係プロパティ (XCommand、XCommandParameter、および XCommandTarget) を作成しました。
• ユーザー コントロール xaml で、「実際の」ボタンをそれらのプロパティにバインドします (各ボタンを各プロパティ セットにバインドします)。
• ユーザー コントロールを使用する場合は、新しいプロパティを実際のコマンド バインドにバインドします。

要するに、ユーザー コントロールが公開する「コマンド」ごとに ICommandSource 機能を維持したいと考えています。ただし、このデュアル データ バインディング シナリオは機能していないようです。または、何か間違っています。:)

これを行うより良い方法はありますか？必要なのは、コマンドをコントロールの外側から内側のボタンに「ブリッジ」して、Execute および CanExecute 機能を維持することだけです。

リスト内のアイテムにはコンテキスト メニューがあります。コンテキスト メニュー項目はルーティングされたコマンドにバインドされます。

リスト コントロールが の場合、コンテキスト メニュー項目は正しく機能しますが、リスト コントロールListBoxを にダウングレードするとすぐにItemsControl機能しなくなります。具体的には、メニュー項目は常にグレー表示されます。私のCanExecuteコールバックCommandBindingも呼び出されていません。

ListBoxコマンドを含むコンテキスト メニュー項目を正しくバインドできるようにするのは何ですか?

問題を強調するためにまとめたサンプルアプリからの抜粋を次に示します。

ビュー モデルとデータ項目の C# コードは次のとおりです。

コントロールの C# コード ビハインドを次に示します。

質問を繰り返します -ListBoxコンテキストメニュー項目コマンドを正しくバインドできるようにするものは何ですか?これを機能させる方法はありItemsControlますか?

RoutedCommandのコンストラクターには、最後の引数として「所有者タイプ」があります。その意義は何ですか？いつ使用しますか？

MSDNのドキュメントには、なぜそれが必要なのか、すべてのコマンドに1つのタイプを使用できるかどうかについての手がかりはまったくありません。

MSDNからの引用

もう1つあります。名前の配列から動的に新しいルーティングコマンドを作成する場合、どのタイプを使用する必要がありますか。どのタイプでも機能するように見えるので、UIElementを使用していますが、これにより適したタイプがあるかどうかを知りたいと思います。

ある方法で WPF コマンド ルーティングを拡張して、コマンドをフォーカスされたフィールドで呼び出すことができるかどうかを最初に確認できますか? そのためのフックはありますか？それが機能するかどうかわからないかもしれませんが、ネット上のどこかで似たようなものを見たので、リンクを惜しみませんか?

抽象的な例

たとえば、サイド パネルを備えたテキスト エディタを作成している場合、パネルにフォーカスがあります。Ctrl+G を押すと、パネルにコマンド バインディングとフォーカスがあるため (通常の WPF 動作)、いくつかのコマンドが呼び出されます。また、Ctrl+H を押しても、今回はパネルに呼び出されたコマンドのコマンド バインドがありません。この場合、ルーティング エンジンをテキスト エディターに切り替えて、同じコマンドをそこに吹き込みたいと思います。

実際の例

[貼り付け] というメニュー項目がありますが、フォーカスはサイド パネルにあります。メニューを押すと、パネルにバインドされたコマンドが実行されます。パネルにバインドされた適切なコマンドがないとします。この場合、テキスト エディターに貼り付けたいと思います。

コード

このコードは、多かれ少なかれこのシナリオを表しています。Ctrl+H を押して CommandBinding_Executed_1 を実行したい

Window1.xaml

Window1.xaml.cs