1

もともと、次のように、ロードされたイベントで実際の treeviewitem の入力バインディングに追加しました。

 void MultiSelectTreeViewItem_Loaded(object sender, RoutedEventArgs e)
    {
      this.InputBindings.Add(new KeyBinding(ApplicationCommands.SelectAll, new KeyGesture(Key.A, ModifierKeys.Control)));
      SignalViewModel svm = this.DataContext as SignalViewModel;
      if (svm != null)
      {
        this.InputBindings.Add(new KeyBinding(DaedalusGraphViewer.GraphViewer.AddSignalsCommand, new KeyGesture(Key.Enter)));
      }
      BitViewModel bvm = this.DataContext as BitViewModel;
      if (bvm != null)
      {
        this.InputBindings.Add(new KeyBinding(DaedalusGraphViewer.GraphViewer.OpenNewBusDialogCommand, new KeyGesture(Key.Enter)));
      }
    }

これの問題は、treeviewitem を別の場所で使用して別のコマンドを使用する場合、毎回新しい treeviewitem クラスを作成する必要があることです。私は間違いなくここで MVVM に違反しており、カップリングが多すぎるため、この古いコードを修正したいと考えています (最近 mvvm のプラクティスを採用しようとしていますが、まだ正しく行われていない古いものがたくさんあります)。

私が望むのは、xaml でキーバインドをアタッチする方法ですが、キーバインドが機能するかどうかを決定するものについてはまだ少し曖昧です。キーバインドが存在するアイテムがフォーカスされている場合にのみキーバインドを使用できますか? 現在フォーカスされているアイテムの親キーバインドまたは子キーバインドにアクセスできますか? 私のテストに基づいて、親からキーバインディングにアクセスできないように見えました。別のスタックオーバーフローの投稿を読んで、子にもアクセスできないように見えました。そうですか?

毎回新しいクラスを作成する必要がないように、テンプレート化可能なツリービューのさまざまな層にキーバインドを設定する、カスタマイズ可能な優れた方法が必要です。

編集:考えられる解決策の1つは、入力バインディングを各層のテキストボックスにそれぞれ異なるコマンドでアタッチし、テキストボックスを引き伸ばして項目を埋め、ツリービューではなくテキストボックスにフォーカスを置くことです。それは最良の選択肢ですか?理想的には、hierarchicaldatatemplate に入力バインディングか何かがあればいいのにと思います。

4

0 に答える 0