WPF: intercettare eventi/comandi

[Giulio Petrucci]

Ciao a tutti,

ho una app WPF formata da più tab all'interno di una stessa shell, con
eventualmente qualche finestra di pop-up. Cercando di minimizzare il
codice da scrivere (in particolare tutto ciò che è boilerplate) tutti
gli eventi della tab (chiusura, perdita/acquisizione di focus, ecc.) più
altri sollevati dall'interno delle tab (pressione di bottoni, ecc.)
siano gestiti a livello della shell.

E' possibile?
Dove devo iniziare a documentarmi?

Grazie e buona giornata/settimana,
Giulio

--

[Raffaele Rialdi [MVP]]

Ciao,
lo scenario che descrivi si presta molto di più ad essere sviluppato
con MVVM piuttosto che con la gestione eventi.

Tanto per darti un'idea, ogni volta che vuoi un contesto di backend
differente (cioè un ViewModel che si occupi di una parte di user
interface) è sufficiente che quella gerarchia di UI abbia il suo
DataContext impostato sul corrispondente ViewModel.
Nel tuo esempio avresti:
- shell bindata al ViewModel della shell
- tab (uno o più) bindati al/ai ViewModel dei tab
- tutti i viewmodel comunicano via mediator pattern la cui
implementazione di solito è "affogata" nell'implementazione di MVVM che
scegli.

Un buon kit è MVVM light che offre molto di più di quanto ti serve in
questo scenario.

Se invece vuoi andare con gli eventi ovviamente dovrai gestirti tutto
nei code-behind e redirigere le richieste su tue classi per
omogenenizzre le richieste, ma è decisamente più complesso.

--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/

[Giulio Petrucci]

Ciao Raf,

grazie per la risposta.

On 29/07/2013 09.48, Raffaele Rialdi [MVP] wrote:
> Ciao,
> lo scenario che descrivi si presta molto di più ad essere sviluppato con
> MVVM piuttosto che con la gestione eventi.

Sì, decisamente meglio così! :-)
Peraltro sto cercando di evtiare come la peste tutto ciò che non sia
100% MVVM...

> Tanto per darti un'idea, ogni volta che vuoi un contesto di backend
> differente (cioè un ViewModel che si occupi di una parte di user
> interface) è sufficiente che quella gerarchia di UI abbia il suo
> DataContext impostato sul corrispondente ViewModel.
> Nel tuo esempio avresti:
> - shell bindata al ViewModel della shell

...ce l'ho!

> - tab (uno o più) bindati al/ai ViewModel dei tab

...ce l'ho!

> - tutti i viewmodel comunicano via mediator pattern la cui
> implementazione di solito è "affogata" nell'implementazione di MVVM che
> scegli.

Ecco, questo mi manca. Il mediator devo implementarlo io? Magari usando
un sistema di messaging/weak event? Ma non è un bel po' di codice da
scrivere a mano?

Io ho fatto una cosa del genere: nel bottone con la "x" che chiude il
tab item, ho messo:

<Button Command="{Binding DataContext.CloseCommand,
RelativeSource={RelativeSource FindAncestor, AncestorType=Window}}" ...>

ed effettivamente il mio CloseCommand, definito nel viewmodel della
shell, viene correttamente richiamato. Il problema è che da dentro al
metodo non c'è modo di tenere traccia di quale tab abbia effettivamente
invocato il comando!
Suggerimenti?

> Un buon kit è MVVM light che offre molto di più di quanto ti serve in
> questo scenario.

Visto che il progetto a cui sto lavorando è molto "didattico", vorrei
evitare di passare tramite MVVM. Ho "rubacchiato" un po' da Radical (e
conto di inserirlo pesanemente a breve), ma nella fase attuale
preferisco scrivere codice a mano. :-)

> Se invece vuoi andare con gli eventi ovviamente dovrai gestirti tutto
> nei code-behind e redirigere le richieste su tue classi per
> omogenenizzre le richieste, ma è decisamente più complesso.

Già... quindi questa soluzione la scartiamo senza neanche un po' di
rimorso. :-)

Grazie,
Giulio

--

[Giulio Petrucci]

On 29/07/2013 10.51, Giulio Petrucci wrote:
[cut]

> <Button Command="{Binding DataContext.CloseCommand,
> RelativeSource={RelativeSource FindAncestor, AncestorType=Window}}" ...>
>
> ed effettivamente il mio CloseCommand, definito nel viewmodel della
> shell, viene correttamente richiamato. Il problema è che da dentro al
> metodo non c'è modo di tenere traccia di quale tab abbia effettivamente
> invocato il comando!
> Suggerimenti?

[cut]

UPDATE:

<Button Command="{Binding DataContext.CloseCommand,
RelativeSource={RelativeSource FindAncestor, AncestorType=Window}}"

CommandParameter="{Binding}">
...
</Button>

:-P

Ciao,
Giulio

--

[Mauro Servienti [MVP]]

Ciao Giulio,

You wrote on 29/07/2013 :
> Ecco, questo mi manca. Il mediator devo implementarlo io? Magari usando un
> sistema di messaging/weak event? Ma non è un bel po' di codice da scrivere a
> mano?

dipende dalle feature che vuoi, non è che ci sia poi molto li dietro.
Guardati il MessageBroker di Radical è abbastanza semplice.

.m

--
blog @ //milestone.topics.it

[Mauro Servienti [MVP]]

Ciao Giulio,

You wrote on 29/07/2013 :

> <Button Command="{Binding DataContext.CloseCommand,
> RelativeSource={RelativeSource FindAncestor, AncestorType=Window}}"
> CommandParameter="{Binding}">
> ...
> </Button>

sarebbe molto più sensato che la "SelectedTab" sia in binding con il
ViewModel anch'essa. Nel senso che deduco ti interessi poco sapere
quale sia effettivamente il TabItem selezionato ma piuttosto quale sia
il ViewModel dietro il TabItem selezionato.

[Giulio Petrucci]

Ciao Mauro,

On 29/07/2013 13.32, Mauro Servienti [MVP] wrote:
> dipende dalle feature che vuoi, non è che ci sia poi molto li dietro.
> Guardati il MessageBroker di Radical è abbastanza semplice.

Ovvio!
Ormai Radical (per quanto mi riguarda) è *IL* framework, non si può
prescindere!
L'unica cosa che non capivo era se Raf alludesse a una qualche
implementazione idiomatica del mediator, ma a questo punto credo di no. :-)

Ciao,
Giulio

--

[Giulio Petrucci]

Ciao Mauro,

On 29/07/2013 13.34, Mauro Servienti [MVP] wrote:
> sarebbe molto più sensato che la "SelectedTab" sia in binding con il
> ViewModel anch'essa. Nel senso che deduco ti interessi poco sapere quale
> sia effettivamente il TabItem selezionato ma piuttosto quale sia il
> ViewModel dietro il TabItem selezionato.

Con lo snippet di codice che ho postato, riesco a far passare il
viewmodel "incriminato" come argomento della .Execute() del comando di
chiusura. Per quanto riguarda quello che scrivi, lo aggiungerò. Però
devo considerare anche il caso in cui venga chiusa una tab non selezionata.
Vediamo come va a finire, poi vi faccio sapere.
Nel frattempo: grazie.
:-)

Ciao,
Giulio

--

[Mauro Servienti [MVP]]

Ciao Giulio,

You wrote on 29/07/2013 :

> Ormai Radical (per quanto mi riguarda) è *IL* framework, non si può
> prescindere!

:-)

[Raffaele Rialdi [MVP]]

Giulio Petrucci wrote:
> Ciao Raf,
>
> grazie per la risposta.

Prego!

>
> Sì, decisamente meglio così! :-)
> Peraltro sto cercando di evtiare come la peste tutto ciò che non sia 100%
> MVVM...
>

:)

>
> Ecco, questo mi manca. Il mediator devo implementarlo io? Magari usando un
> sistema di messaging/weak event? Ma non è un bel po' di codice da scrivere a
> mano?
>

Tipicamente tutti i framework di MVVM ce l'hanno... come anche ti ha
già detto Mauro.
Io nelle app win8 ho trovato un'alternativa al mediator perché parte
dal presupposto della navigazione in contrasto a un numero di view
indipendenti. Ma questo si presta poco alle app WPF.


>
[...]

>
> Visto che il progetto a cui sto lavorando è molto "didattico", vorrei evitare
> di passare tramite MVVM. Ho "rubacchiato" un po' da Radical (e conto di
> inserirlo pesanemente a breve), ma nella fase attuale preferisco scrivere
> codice a mano. :-)
>

Ho visto che hai già risolto e sei già sulla strada buona.
Concordo con Mauro che è meglio che il selectedtab sia segnalato al
viewmodel.

buon lavoro...