Discussion :

[tomlev]

Salut,

Comme vous l'avez peut-être remarqué, la propriété Command d'un InputBinding n'est pas une DependencyProperty, si bien qu'on ne peut pas binder un InputGesture sur une commande du ViewModel. J'ai pas mal cherché comment on pouvait contourner cette limitation, par exemple en héritant de InputBinding ou en passant par une propriété attachée, mais en fait ça ne règle pas le problème, car les InputBindings déclarés dans le XAML n'héritent pas du DataContext

J'ai trouvé quelques ressources intéressantes sur le sujet :
http://social.msdn.microsoft.com/For...-1959cf36a8f7/ => la solution proposée est vraiment trop complexe à mettre en oeuvre...
http://stackoverflow.com/questions/6...vm-application => idem
http://groups.google.com/group/wpf-d...a4990bea96340f => Discussion très intéressante avec plusieurs gourous de WPF (Josh Smith, John Grossman...), mais au final aucune solution concrète

Il me semble que ça ne devrait pas être très compliqué à faire, et pourtant, j'ai beau chercher, je ne trouve aucune solution simple

Comment gérez-vous les raccourcis clavier ou souris en MVVM ? Y a-t-il une solution simple qui m'a échappé ?

Merci d'avance !

[Thomas Lebrun]

Comment gérez-vous les raccourcis clavier ou souris en MVVM ? Y a-t-il une solution simple qui m'a échappé ?

Je n'ai jamasi eu l'occasion de mettre en place les raccourcis clavier avec MVVM mais je vois effectivement le problème sans avoir de solution viable

[Jérem22]

J'ai également moi aussi rencontré le problème (la propriété Command n'est pas un DP)... Pour l'instant je m'en suis sorti en utilisant ponctuellement le code-behind, par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
this.searchTextBox.InputBindings.Add(new KeyBinding(
  this.searchViewModel.SearchCommand,
  new KeyGesture(Key.Enter)));

J'avoue que je ne suis pas du tout satisfait du résultat... Peut être que Command deviendra une DP dans .Net 4 :p

[tomlev]

Merci pour vos réponses

J'ai également moi aussi rencontré le problème (la propriété Command n'est pas un DP)... Pour l'instant je m'en suis sorti en utilisant ponctuellement le code-behind, par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
this.searchTextBox.InputBindings.Add(new KeyBinding(
  this.searchViewModel.SearchCommand,
  new KeyGesture(Key.Enter)));

Effectivement ce serait une solution... mais je préfèrerais éviter de passer par le code-behind, et surtout de référencer explicitement le ViewModel dans la View...

Peut être que Command deviendra une DP dans .Net 4 :p

Ce serait un bon début, mais pas suffisant malheureusement... D'après ce que j'ai pu lire, les InputBindings ne font pas partie du visual tree ni du logical tree, et n'héritent pas du DataContext (ce qui explique le problème décrit dans le 3e post du premier lien que j'ai donné). J'ai l'impression qu'il y a comme un problème de conception dans WPF à ce niveau là . Dommage...

Si jamais je trouve une solution viable, je vous tiendrai au courant

[Jérem22]

Tu pourrais peut être regarder du côté d'Onyx (http://wpfonyx.codeplex.com/) qui est un framework pour utiliser MVVM.

Peut être que le créateur du projet a prévu quelque chose de ce côté là (j'ai pas eus le temps d'essayer...).

[The_badger_man]

Effectivement ce serait une solution... mais je préfèrerais éviter de passer par le code-behind, et surtout de référencer explicitement le ViewModel dans la View...

Pourquoi ? Tu as de toute façon forcément une référence sur le ViewModel étant donné que tu te bind dessus ?
Et puis tu ne fais qu'écrire en C # se qui aurait dû l'être en XAML mais tout en restant dans la même classe (la vue). Est-ce vraiment casser la pattern que d'écrire du code pour suppléer le XAML si ce n'est pas possible de faire autrement?

[tomlev]

Pourquoi ? Tu as de toute façon forcément une référence sur le ViewModel étant donné que tu te bind dessus ?

Oui, mais normalement la vue n'a pas besoin de connaitre explicitement le type du ViewModel. On l'affecte simplement au DataContext, et le binding récupère dynamiquement les propriétés et commandes. En principe, on devrait pouvoir remplacer le ViewModel sans changer quoi que ce soit à la vue...

Et puis tu ne fais qu'écrire en C # se qui aurait dû l'être en XAML mais tout en restant dans la même classe (la vue). Est-ce vraiment casser la pattern que d'écrire du code pour suppléer le XAML si ce n'est pas possible de faire autrement?

Ce qui me gène, ce n'est pas tant d'écrire du code behind, mais de mettre une dépendance en dur sur le ViewModel. Enfin, de toutes façons j'ai l'impression qu'il n'y a pas trop le choix . Donc en attendant mieux c'est ce que je vais faire