Tradotta in italiano la parola trigger identifica qualcosa in grado di scatenare un innesco, o anche un qualcosa che è capace di scatenare un qualche processo.

Non a caso un altro significato della stessa parola è grilletto !

La stessa parola viene anche utilizzata in WPF per identificare una funzionalità utilizzata in tandem con gli stili, e che, seguendo il significato originale della parola, permette di cambiare il look and feel dei controlli allo scatenarsi di determinati eventi o condizioni prestabilite.

Per esempio si immagini di voler cambiare l’aspetto di un controllo qualora il mouse si trova sopra questo: in questo caso la causa scatenante è il mouse posizionato sopra un controllo, e l’effetto che si vuole ottenere è che il controllo stesso cambi qualche elemento dello stile.

Certo: è possibile ottenere questo risultato con l’ausilio di codice C# associato e determinati eventi. Purtuttavia è possibile ottenere lo stesso effetto anche con l’ausilio di sole dichiarazioni WPF e l’ausilio dei trigger.

Ora Vi prego: non “cambiate canale”. L’esempio proposto sopra per illustrare l’uso dei trigger può sembrare poco interessante: un controllo che cambia aspetto quando il mouse si posiziona sopra di esso è molto “anni ‘90” e quando mi capita di vederlo in qualche maschera mi provoca tenerezza.

In realtà vedremo a breve che i trigger risultano essere indispensabili in altri ambiti decisamente molto più interessanti.

WPF offre diverse tipologia di trigger che Vi esplicito nel seguito.

- Property trigger – è il trigger più utilizzato e viene attivato non appena una proprietà di un controllo assume un determinato valore.

- Multi-trigger – come quello precedente, solo che viene attivato quando diverse proprietà assumono contemporaneamente determinati valori.

- Event trigger – viene attivato quando un determinato occorre.

- Data trigger – viene azionato quando dei dati in binding cambiano valore.

In questa serie per brevità ho pensato di lasciare fuori gli event trigger, poiché li ritengo meno interessanti rispetto agli altri.

Se il codice che produco è passibile di mille critiche, le maschere che mi capita di creare sono indubbiamente e sicuramente delle schifezze immonde.

Il bottone lo metto sempre nella posizione sbagliata, e così le caselle di testo, per non parlare del colore assegnato ai controlli: i miei colleghi diventano matti a sistemare le UI che creo in modo che siano non dico utilizzabili, ma che almeno siano presentabili.

Per questo motivo non mi trovo a mio agio a parlare di aspetto dei controlli UI WPF: semplicemente non è il mio campo !

Però siccome nelle prossime parti occorrerà mettere mano allo stile dei controlli, per lo meno quando si parlerà della validazione dei dati inseriti, occorre che ne scriva qualcosa !

Prima di proseguire oltre occorre sviscerare lo scopo e gli utilizzi della tipologia dei controlli WPF che permettono di sistemare il layout di una pagina.

Nativamente una pagina realizzata con la tecnologia WPF può contenere un solo elemento grafico: se si vogliono disporre più elementi (e noi lo vogliamo: una maschera con solo un bottone servirebbe a poco, non trovate ??) occorre usare un qualsiasi controllo di tipo layout.

Tramite questo tipo di controllo sarà possibile disporre gli altri controlli sulla maschera.

Esistono in WPF svariati tipi di tipi di controlli layout, ognuno dotato delle sue peculiarità: qui esporrò solo quelli che ritengo i più importanti.

StackPanel

Lo StackPanel è un controllo layout che semplicemente dispone gli elementi da lui contenuti uno dopo l’altro: la cosa interessante è che l’orientamento può essere sia verticale che orizzontale.

Per ragioni professionali recentemente ho fatto docenza per alcuni corsi che avevano come oggetto l'insegnamento di Windows Presentation Foundation (WPF): questa serie di post prende spunto proprio dagli appunti che ho approntato allo scopo.

WPF è la nuova tecnologia che permette di costruire le maschere UI e che può essere considerata come un’evoluzione delle Windows Forms: oramai è da cosiderarsi de facto IL metodo da usare per creare maschere per applicativi moderni.

Oggettivamente ci vuole parecchio coraggio nel definire WPF una “nuova” tecnologia: infatti questa è largamente adottata da anni ed è tanto diffusa che ritengo assurdo e controproducente disegnare maschere per nuovi software scritti in .Net usando tecnologie differenti.

Purtroppo per parlare in modo efficace e sensato di WPF penso che non si possa prescindere dall’utilizzare il pattern Model-View-ViewModel MVVM, che rappresenta il reale completamente della tecnologia.

Inoltre l’adozione del pattern MVVM è efficace solo se utilizzato in tandem con un sistema di Object-relational mapping (ORM), per permetterne l’interazione con la base dati.

Per tale motivo in questa serie troveranno posto diverse parti in cui tenterò di esporVi non solo le idee fondanti del pattern MVVM, ma anche i rudimenti principali di Entity Framework, che è l’ORM proposto da M$.

Se questi termini Vi sembrano astrusi non preoccupatevi: se mi seguirete in questa serie Vi assicuro che farò del mio meglio per schiarirVi un po' le idee.

Se invece siete confidenti con loro…. bè….. allora questa serie non fa per Voi.

Avviso iniziale: il livello degli argomenti è molto basic, ma per ognuno di questi ho cercato di dargli un taglio assolutamente pratico e applicativo. Detto in altri termini l'intento è quello da fornire gli strumenti per costruire da subito alcune semplici maschere usando questa tecnologia, ma per affrontare degli sviluppo serio va da sè che occorre approfondire diverse parti rispetto a quanto presentato.

Altro avviso: il primo impatto con WPF è molto forte….. ma è un come andare in bici la prima volta: sembra impossibile ma dopo un poco ci si accorge che si può fare facilmente.

E quindi….. facciamoci insieme stò giretto in bici… con le rotelle per ora…..