Studenti in grado di cambiare il mondo: questa è l’idea che ha ispirato Microsoft nel creare Imagine Cup, la competizione globale che incoraggia giovani talenti a utilizzare immaginazione, passione e creatività per contribuire all’innovazione tecnologica.

La più grande competizione mondiale di informatica giunge all’ultimo stadio delle selezioni nazionali: i team finalisti si confronteranno il prossimo 19 e 20 maggio presso la Sala Azzurra dell’Università Federico II di Napoli. Il primo classificato rappresenterà l’Italia alle finali mondiali che si terranno a Varsavia dal 3 all’8 luglio. Nella prima giornata gli studenti presenteranno il proprio progetto ad una giuria di esperti provenienti dal mondo accademico, dalla stampa e dall’ambito tecnologico (industria IT) che selezioneranno le migliori idee. La seconda giornata sarà dedicata alla premiazione dei vincitori per ciascuna categoria d’appartenenza.

I progetti dei nostri studenti mirano a “risolvere i problemi più ardui del pianeta” ispirandosi agli 8 Millennium Development Goals stabiliti dalle Nazioni Unite, in 3 categorie: progettazione di software (Software Design), di giochi (Game Design) e design di interfacce interattive (Surface Interaction Design).

Congratulazioni ai vincitori, che vi presentiamo in rigoroso ordine alfabetico:

La giornata del 19 è aperta al pubblico e sarà introdotta da Microsoft e Avanade, seguite da David Platt con lo speech Why Software Sucks...

Ecco l’agenda:

Per coloro che presenteranno la conferma di registrazione la t-shirt ufficiale di Imagine Cup.

Link utili:

• Il blog ufficiale italiano di Imagine Cup
• Imagine Cup su Facebook

Vi aspettiamo a Napoli il 19 maggio!

Mauro Minella – Microsoft Academic Relations

L’università è il vivaio dove crescono i guru e i leader tecnologici di domani, i giovani rappresentano coloro che aiuteranno la ripresa nelle aziende italiane in un futuro molto vicino, dalla scuola nasceranno gli autori dei libri che leggeremo fra qualche anno.

Spesso, l’incontro con il mondo del lavoro è un momento difficile per molti studenti: è il momento in cui si passa dalla teoria alla pratica, il momento in cui ci si confronta con aziende che hanno modelli di sviluppo profondamente diversi da quelli perfetti studiati sui libri. Dall’altra parte, le aziende sono il vivaio dove nascono i prodotti di domani, le persone che vi lavorano partecipano a conferenze professionali per aggiornare le proprie competenze e si rivolgono a esperti del settore per progettare e realizzare le proprie soluzioni.

.NET Campus nasce per far incontrare questi due mondi.

Speaker professionisti provenienti dalle Aziende e Community IT più attive sul territorio, coordinati dal gruppo DevLeap supportato dal team italiano dei Microsoft Student Partner e formato da professionisti che affiancano da anni Microsoft in conferenze ed eventi professionali si alterneranno per una full immersion di tecnologia nelle aule dell’Università Roma3 –che rimarrà aperta di sabato per l’occasione- il prossimo 13 marzo; sarà un momento di formazione sia per studenti che per aziende, un’occasione per incontrare gli esperti del settore, per capire come muoversi e dove investire nell’immediato futuro e, non ultimo, un momento un cui imparare le infinite possibilità che questo settore offre a tutti coloro che hanno voglia di impegnarsi.

Se sei uno studente, porta il tuo curriculum vitae! Potrai consegnarlo direttamente alle aziende e alle persone che ruotano intorno alla manifestazione. Se sei un professionista IT che già lavora in .NET e vuoi vedere in anteprima le novità attese nei prossimi mesi, o lavori in Java e sei interessato a valutare le possibilità di integrazione fra le due tecnologie più importanti sul mercato, non perdere questa occasione: 5 tracce parallele copriranno le aree di WEB, Linguaggi, Interaction Design, Sviluppo Mobile e opportunità di lavoro e formazione, quest’ultima curata dalle aziende coinvolte.

Le iscrizioni sono aperte già oggi: assicurati un posto in prima fila. Ci vediamo a Roma3!

www.dotnetcampus.it

I due ambienti di sviluppo possono coesistere senza problemi, tuttavia bisogna tenere presente che SQL Server Express 2005 -installato automaticamente da VS2008- viene sostituito dal setup di VS2010 con SQL Server Express 2008.

A prima vista questo potrebbe essere considerato un non-problema, considerato che anche un progetto creato con la versione 2008 di Visual Studio può aprire un DB di SQL Server 2008. Tuttavia, l’IDE di VS2008 –e in particolare la sua finestra “Esplora Server”– non sono in grado di aprire database di SQL Server 2008, riportando uno dei due errori di seguito elencati:

Per essere precisi, il primo messaggio di errore compare aprendo un comune database di formato SQL Server 2008, mentre il secondo viene mostrato quando si tenta di aprire il database creato automaticamente dal programma WSA (Web Site Administration tool) di ASP.NET, che serve ad impostare i criteri di protezione, gli account utente ed altre impostazioni del sito ASP.NET che state creando.

Per ovviare al problema e per poter continuare a tenere le mie presentazioni in pubblico su ASP.NET con la versione 2005 di Visual Studio 2005 (incluse le funzionalità integrate di accesso ai dati), ho installato nuovamente SQL Server 2005 chiamandolo SQLSERVER2005 per distinguerlo dalla versione 2008 già installata (per default con il nome di SQLEXPRESS), ritrovandomi così due servizi distinti:

Ora, da una parte il problema è risolto ricordandosi di specificare il corretto motore di SQL Server quando si crea un database SQL Server dall’interno della finestra “Esplora Server” di Visual Studio 2005:

Dall’altra parte però il problema persiste quando creo un database dal menu contestuale “Aggiungi nuovo elemento” sul progetto (perché non fa comparire la finestra di cui sopra, e usa la connessione a SQLEXPRESS di default).

Ma soprattutto il problema si presenta quando lancio il WSA che menzionavo prima, il quale pure usa la stringa di connessione “LocalSqlServer” definita per default a livello di macchina.

Il primo di questi due problemi si risolve modificando le seguenti due voci all’interno del menu “Strumenti – Opzioni – Strumenti di database” di Visual Studio 2005, facendo così puntare l’istanza corretta del database:

1. Connessioni dati
2. Database di convalida

L’altro problema, relativo al WSA, si può risolvere in due modi:

1. Sovrascrivere, in ogni applicativo WSA dove si vogliano mantenere le connessioni sull’istanza SQL Server 2005, la stringa di connessione “LocalSqlServer” con una che punti a server corretto, all’interno del file WEB.CONFIG; nel mio caso l’ho modificata come segue:
   <connectionStrings>
     <remove name="LocalSqlServer"/>
     <add
       name="LocalSqlServer"
       connectionString="data source=.\SQLEXPRESSEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
       providerName="System.Data.SqlClient"/>
   </connectionStrings>
   
   
2. L’altro metodo è più radicale e bisogna tenere in considerazione che tale impostazione influenza anche Visual Studio 2010; esso consiste nel modificare la stringa di connessione “LocalSqlServer” accessibile dal pannello di amministrazione di IIS, facendola puntare nel mio caso all’istanza di SQLSERVER2005:
   
   

Chi è interessato trova a questo link, qui sul mio blog, le esercitazioni complete di database e script che guidano passo passo alla realizzazione di un sito WEB di commercio elettronico in ASP.NET.

Buon lavoro

L’immediata conseguenza di indicare le misure in pixel, e questo lo sanno anche i sassi, è che l'interfaccia risulta più grande al diminuire della densità: se cambiate la risoluzione del vostro schermo da 1280x1024 a 800x600 e mantenete uguale l’area visibile vi troverete gli oggetti più grandi del 60% perché di fatto questa è la crescita che ciascun pixel ha avuto; apro e chiudo una parentesi, anche questo tutti lo sanno ma repetita iuvant: i monitor LCD hanno una risoluzione nativa e cambiarla equivale a fare sì che il software del monitor (NON della scheda grafica) riscali la nuova risoluzione su quella nativa, con un peggioramento evidente della qualità; come vedremo più avanti, la strada da seguire per ingrandire l’immagine è agire sui DPI, NON sulla risoluzione.

Ma allora, che unità di misura utilizza WPF? Il millimetro, il centimetro, il pollice, il metro? Fuochino. Nel senso che utilizza un’unità di misura appunto indipendente dalla risoluzione; quindi invece di dire che un bottone è largo 100 pixel, imposta per esempio la sua misura a 2 centimetri; a quel punto, quando l’utente si sposta su un monitor che ha una densità di pixel diversa –come negli esempi sopra- il bottone dovrebbe continuare a misurare 2 centimetri.

Perché dico dovrebbe? Beh, perfino chi ha già sviluppato in WPF -e non si è posto il problema- probabilmente non non ha ancora notato la differenza nel sistema di misura di WPF rispetto agli altri; anzi, avrà notato il contrario: cambiando monitor, anche gli oggetti WPF cambiano di dimensione; addirittura, rimanendo sullo stesso monitor e cambiando risoluzione, le applicazioni WPF scalano esattamente come le Windows Forms e le applicazioni WEB. Spiegherò il perché di tutto questo fra un momento.

Lasciatemi prima dire, anche se è un dettaglio, qual è l’unità di misura indipendente dalla risoluzione (che di seguito chiamerò DIU: Device Independent Unit) che usa WPF; tenetevi forte: 0,026458333333 centimetri; comodo da ricordare, vero ;-) ? Per avere un’idea più pratica, considerate che è circa un quarto di millimetro. Ma probabilmente la fissiamo meglio in mente se consideriamo che ci sono esattamente 96 DIU ogni 2,54 centimetri. In altre parole 1 DIU = 1/96 di pollice. Quindi se vogliamo fare un bottone largo 1 pollice dovremo indicare Width="96", e ovviamente 10 centimetri misurano 377,95 DIU.

Torniamo all'osservazione di prima: prendo un righello, lancio Visual Studio, metto sulla form WPF un bottone da 96 DIU, lo misuro e... mi accorgo che NON è largo necessariamente un centimetro! Abbasso la risoluzione, diventa più largo, vado su un altro PC e cambia ancora... ma allora dov’è la blasonata RESOLUTION INDEPENDENCE di WPF? Il punto è che WPF si basa sulle impostazioni di sistema, non sulle impostazioni del device fisico (il monitor); se ci pensate un momento, questo ha perfettamente senso: come fa il vostro sistema a sapere quanti centimetri è largo il vostro monitor? Come fa a sapere la distanza del telo dal prioettore collegato alla vostra uscita video, visto che le dimensioni dell’immagine dipendono da questa? Non lo sa. A meno che non siate voi a dirglielo. Come? Fate le misurazioni (vedi l’esempio introduttivo di questo post, dove calcolavo 130 DPI) e specificatele nel Pannello di Controllo (sezione DPI Scaling) come indicato di seguito:

A questo punto impostate Width="377.95" nei parametri del bottone (sì, avete letto bene: i DIU si specificano in double) , prendete il righello e verificate se non ci credete: il bottone è largo 10 centimetri, su qualunque monitor e, naturalmente, anche se lo stampate su una LASER da 1200 DPI o su una ad aghi!

Provate a fare la stessa cosa con un’applicazione tradizionale in finestra o WEB: non si può, o meglio in teoria potreste farlo ma non certo utilizzando un’unica misura (377,95): dovreste contare quanti pixel ci vogliono per fare 10 centimentri e cambiare la dimensione di conseguenza di dispositivo in dispostivo; per curiosità e piacere di calcolo: se impostate Width="377.95", WPF accende ben 512 pixel sul monitor da 130 DPI in risoluzione nativa di 1680x1050 e solo 236 su un monitor largo uguale che abbia però una risoluzione nativa di 800x600, ma entrambi i casi la misura è sempre 10 centimetri, e in tutti i casi la misura che voi avete specificato con WPF è sempre la stessa (377,95 DIU)!

Ora anticipo la prossima obiezione, che qualcuno di persona mi ha già fatto: d’accordo, ora è chiaro come tracciare misure fisse indipendenti dalla risoluzione. Ma a me non interessa. Io voglio continuare a beneficiare del fatto che sia l’utente a scegliere le dimensioni della mia applicazione semplicemente cambiando la risoluzione del monitor oppure, ma solo se è lui a deciderlo, modificando il DPI Scaling. Ebbene, non a caso il DIU misura 1/96 di pollice; infatti, per default quando installate Windows, la scala è impostata 96 DPI (vedi immagine sopra). Ciò significa che, se non viene cambiato il valore 96 di default, 1 DIU = 1 PIXEL. Quindi sviluppando in WPF avete entrambi i benefici: per default, funziona tutto come prima, ma se la vostra applicazione deve gestire dimensioni reali basta che chiediate all’utente di impostare DPI Settings al valore corretto per il suo monitor (semplicmente dividendo la larghezza del monitor per la risoluzione orizzontale); immaginate per esempio una calcolatrice touch screen: sarebbe molto scomodo che, portandola sul un monitor da 52 pollici full HD, occorresse uno spillo per premere i bottoni sul video per evitare che la punta del vostro dito pigi 3 bottoni insieme.

Infine, e sarà argomento di un prossimo post, seguendo questa strada con WPF diventa semplice scalare gli oggetti di interfaccia: avete mai visto un’applicazione che quando è portata a pieno schermo ingrandisce in proporzione tutti gli elementi contenuti nella finestra? Very complicato da implementare in un’applicazione tradizionale. Questo è il motivo per cui spesso si leggono warning del tipo l’applicazione richiede una risoluzione di 1024x768 o simili, che vogliono appunto dire che se hai risoluzione maggiore la vedi piccola, mentre se vai in 800x600 ti occupa più dello spazio visibile... non sarebbe meglio invece vederla per tutta la larghezza disponibile, eventualmente più definita al crescere della risoluzione?

Concludo con un parallelo, sempre relativo a WPF, fra Resolution Independence e Time Independence: in WPF quando portate un’animazione da un PC lento ad uno molto veloce, questa non accelera: come è giusto che sia, semplicmente diventa più fluida. Anche questo argomento sarà oggetto di un prossimo post.

Riferimenti

• Matthew MacDonald: Pro WPF in C# 2008 - Introducing WPF, by Apress, capitolo in parte riportato qui
• Charles Petzold: Applications = Code + Markup - Capitolo 1, by Microsoft Press
• Adam Nathan: Windows Presentation Foundation Unleashed - Enter WPF, by SAMS

Vi suggerisco di vedere prima lo screencast che segue -dura circa 10 minuti-, per avere un'idea di come si realizza un'applicazione di questo tipo, e poi provare a realizzare nuovamente la stessa seguendo passo passo il resto di questo post. Trovate i sorgenti del progetto a questo link.

Una volta predisposta una macchina per creare ed ospitare applicazioni WCF, il primo passo per capire come funziona WCF consiste nel studiarne l'ABC, non solo in senso figurato:

• A sta per Address, ovvero DOVE avviene la comunicazione; nella pratica, questo è l'URL utilizzato internamente per mappare richieste e risposte.
• B sta per Binding, cioè COME si comunica: tramite HTTP, TCP, NamedPipes, MSMQ, o altro protocollo che client e server entrambi capiscono.
• C è il Contratto: che COSA client e server si dicono; in particolare, esistono due tipi di contratto:
  • Data Contract: le informazioni che client e server si scambiano, la cui struttura è indicata nello schema del servizio;
  • Service Contract: i metodi invocati sul vostro servizio dal client, la cui firma (in gergo signature) è contenuta nel WSDL.

Partiamo lanciando Visual Studio 2008, ricordando di lanciarlo in modalità Amministratore se intendete utilizzare il server WEB della vostra macchina Windows Vista; ciò non è necessario se utilizzate il Personal Web Server.

Creiamo un nuovo progetto di tipo WCF (File-New Web Site...), scegliamo un nome e premiamo OK. Noterete che, come spesso succede, il progetto non è esattamente vuoto perché Visual Studio ci ha favorito inserendo qualche piccola porzione di codice, che normalmente lo sviluppatore deve sempre scrivere; in questo caso, però, poiché vogliamo capire esattamente i dettagli di WCF, lo "puliremo" quasi per intero.

Apriamo innanzi tutto il file App_Code\IService.cs e rimuoviamo tutto il codice tranne gli using iniziali che referenziano i namespace. In questo file si specifica l'interfaccia del servizio in termini di dati e metodi attraverso cui il servizio si espone all'esterno; notate la corrispondenza fra questi due termini e i due tipi di contratto che ho indicato sopra con lo stesso colore.

Partiamo con il Data Contract: definiamo due tipi che useremo per comunicare; potremmo usare tipi semplici come string e int, ma per fare un esempio semplice e al tempo stesso estensibile userò però due classi, ciascuna con un membro pubblico: chiamerò la prima Richiesta e la seconda Risposta:

Ora, affinché la classe sia serializzabile, l'autore deve definire il data contract che dicevo sopra. L'attributo [DataContract], applicato ad una classe o ad un tipo, specifica che la classe (o il tipo) definisce o implementa un data contract ed è serializzabile da un serializatore come System.Runtime.Serialization.DataContractSerializer; in modo simile, l'attributo [DataMember] deve essere applicato ad ogni membro pubblico che si vuole esporre della classe serializzata. Ecco quindi come devono essere modificate le due classi sopra per diventare parte del data contract:

Oltre al Data Contract io voglio ora implementare il Service Contract: in altre parole, voglio esporre un metodo. Tale funzione, che chiamerò RendiMaiuscolo, accetta un oggetto di classe Richiesta e restituisce un oggetto di classe Risposta creato all'interno della funzione stessa; si noti che così come il Data Contract richiede la coppia [DataContract] / [DataMember], in modo simile il Service Contract richiede l'attributo [ServiceContract] prima della definizione dell'interfaccia, e [OperationContract] per la definizione del metodo; in pratica, scriveremo così la sua signature:

Il prossimo passo consiste nell'implementare il contratto (in particolare il suo Service Contract) appena definito: apriamo il file App_Code\Service.cs, rimuoviamo tutto il codice e implementiamo l'interfaccia; si può anche chiedere a Visual Studio di generare il metodo automaticamente premendo il tasto destro sul nome dell'interfaccia IService da cui si eredita, come mostrato di seguito:

Le seguenti tre righe di codice creano un nuovo oggetto di tipo Risposta ed assegnano al suo membro StringaRisposta la stringa contenuta nell'oggetto richiesta che viene passato al metodo, trasformata in maiuscolo:

Per completezza di informazione aggiungo che l'ultimo snippet di codice avrebbe potuto contenere l'attributo [ServiceBehaviour] prima della definizione della classe Service che deriva dall'interfaccia IService, e l'attributo [OperationBehaviour] prima dell'implementazione del metodo RendiMaiuscolo; tuttavia, questi attributi sono opzionali.

Con l'ultima operazione abbiamo terminato la scrittura del servizio; provate a compilarlo, non devono esserci errori. È giunto quindi il momento di consumarlo.

A questo proposito aggiungiamo alla soluzione un nuovo progetto di tipo WPF (nel mio caso l'ho chiamato WpfApplication1) e un riferimento all'oggetto che implementa l'interfaccia IService appena sviluppata; si noti che premendo il bottone Discover, Visual Studio analizza la soluzione e ne mostra i servizi disponibili, quindi non dobbiamo far altro che selezionare l'oggetto che ci serve specificando un namespace per noi significativo (io l'ho chiamato ServizioDiTest):

Da questo momento in avanti è possibile utilizzare proprietà e metodi pubblici del servizio attraverso l'oggetto ServizioDiTest.ServiceClient.

Per testarlo, aggiungete un oggetto TextBox e un Button nel file Window1.XAML:

in modo da generare l'event handler dell'evento Click nel file Window1.xaml.cs, che riempiremo con queste 6 righe di codice che instanziano il servizio, usano il suo riferimento per creare l'oggetto richiesta e per creare un riferimento risposta alla classe Risposta di cui il servizio crea l'istanza nel metodo RendiMaiuscolo.

Impostate ore l'applicazione WPF come startup project e lanciatela: premendo il bottone, la stringa verrà convertita in maiuscolo:

In effetti l'argomento non è dei più intuitivi, specie per chi proviene da un tipo di sviluppo procedurale classico e non ha particolare esperienza di programmazione procedurale. Inoltre, al fine di cogliere appieno i vantaggi di questa tecnologia, occorre conoscere concetti quali i delegate, le lambda expression, il linguaggio SQL, i Dataset, un po' di XML e chiaramente il framework .NET con almeno un linguaggio fra C# e VB.NET.

Ciò premesso, i takeaways dell'intera presentazione su LINQ sono essenzialmente i seguenti:

• il linguaggio di interrogazione, SQL-like, si integra nel linguaggio di sviluppo (al momento C# 3.0 e VB.NET 9.0)
• tratta i dati come oggetti, e viceversa
• permette il passaggio dalla modalità imperativa a quella dichiarativa: è un po' la differenza che passa fra dare indicazioni di svolta a destra/sinistra/avanti/indietro ad un tassista invece che comunicargli una volta solamente l'indirizzo di destinazione
• funziona in modo molto simile per la gestione di dati, oggetti e stream XML

Le slide che trovate quindi a questo link sono quindi in minor numero rispetto al solito -fra l'altro, le prime tre riprendono i concetti (necessari) del Framework .NET-, ma come vi dicevo gran parte della presentazione prevede la scrittura di demo live per circa 90 minuti.

Seppure corredata di demo live che svolgo al momento, la sessione è pur sempre teorica; viene per questo completata da una esercitazione pratica, che i ragazzi possono svolgere sui PC dell'Università o personali. Trovate qui gli script di laboratorio, e in questo mio post precedente le istruzioni per predisporre la vostra macchina.

Ho presentato questo argomento recentemente a Salerno e Catania. Se siete in zona, e interessati, mi trovate a Venezia il 10 aprile, a Napoli il 15/4, a Milano Bicocca il 17/4, a Bologna il 27/5 e a Torino l'11 giugno; più in generale, trovate le date dei nostri eventi pubblicate sul sito degli studenti (http://www.microsoft.com/italy/studenti/).

Una dependency property dipende da diversi provider per determinare il suo valore in ogni momento; l’obiettivo è di permettere funzionalità avanzate direttamente dall’interno del linguaggio di markup, senza bisogno di impostare le proprietà con codice procedurale.

Implementazione di una Dependency Property

Le dependency property sono normali proprietà di classi .NET che hanno una particolare struttura che le rende fruibili da WPF in modo speciale; nessun altro linguaggio .NET a parte XAML le riconosce come tali.

Per convenzione, tutti i campi DependencyProperty sono pubblici, statici e hanno il suffisso Property.

Poiché le dependency property sono campi statici, esse consumano una quantità di memoria di molto inferiore rispetto a che se fossero tipiche proprietà .NET di cui esiste in memoria una copia per istanza. Non a caso, 78 proprietà su 96 dei bottoni sono dependency property.

Una dependency property è implementata attraverso una chiamata al metodo statico DependencyProperty.Register che richiede un nome (es. IsMouseOver), un tipo (es. bool), il tipo della classe che le espone (es. Button) e, nella maggioranza dei casi, il nome della funzione di callback che viene chiamata quando tale proprietà cambia.

Change Notification

L’implementazione della callback nelle dependency property prende il nome di Change Notification; per rimanere nell’esempio precedente, la proprietà IsMouseOver permette di legare il suo valore (che dice quindi se il mouse si trova effettivamente sul controllo che la utilizza) ad un’altra proprietà del controllo stesso, come Background. Ciò significa che in questo caso non è necessario gestire il background del controllo andando a scrivere codice per l’event handler di MouseEnter e MouseLeave come vorrebbe il metodo classico, il quale fra l’altro “sporca” la business logic del file C# con codice di gestione del layout.

Grazie all’implementazione descritta nel punto precedente, è invece possibile legare il cambiamento di valore di IsMouseOver (da True a False o viceversa) al valore della proprietà Background del bottone.

Il video che segue mostra appunto come sfuttare le dependency property per impostare il colore di un bottone quando il mouse ci passa sopra. Normalmente potremmo implementare questo comportamento andando a definire e poi implementare, in codice procedurale C# o VB.NET, gli event handler per gli eventi di MouseEnter e MouseLeave. Grazie alle dependency property, invece, è possibile implementare questo comportamento solamente usando il codice di markup (XAML). Vediamo quindi come effettuare questa operazione, prima con il metodo classico e poi con le dependency property. Buona visione.

Le "principali azioni" relative ai comandi sono tre: 1) la loro esecuzione, 2) la verifica sul fatto che possano essere effettivamente eseguite e 3) la notifica dello stato di cambiamento della loro disponibilità; per fare un esempio, la funzione incolla prevede come esecuzione l'estrazione dell'informazione dalla clipboard e la sua scrittura nell'elemento di destinazione (es. una TextBox), prevede come verifica il fatto che esista un'informazione in clipboard e come notifica il fatto che la clipboard passi da vuota a piena o viceversa; in questo modo posso utilizzare le tre funzioni per abilitare o disabilitare un bottone che ne implementa il comportamento.

Una volta associato il comando ai nomi delle tre funzioni di risposta (per la precisione questa operazione si chiama CommandBinding), è possibile sfruttare un altro potente servizio offerto da WPF per legare il comando ad un controllo che può essere di tipo Button, CheckBox o MenuItem; da quel momento, premere il bottone richiamerà la funzione designata alla esecuzione, e la proprietà IsEnabled dello stesso sarà automaticamente legata al risultato della funzione di verifica. In più, se il comando prevede una combinazione di tastiera (come il CTRL-V per la funzione Incolla), digitando la stessa otteniamo gratis il biding dello shortcut alla funzione di esecuzione, esattamente come se avessimo premuto il bottone ad essa riferito.

Non vi ho convinto? In effetti, per chi proviene come me da esperienza di programmazione procedurale, risulta a volte difficile percepire il vantaggio di un sistema -come WPF- che fornisce già integrato il supporto per operazioni che siamo sempre stati finora abituati a gestire manualmente: che problema c'è? - mi sono chiesto la prima volta che ho studiato questo argomento - basta scrivere l'operazione nella funzione di risposta al click del bottone. 

Per meglio rendermi conto della differenza ho provato ad implementare la funzione incolla in modo tradizionale e poi sono passato al command binding di WPF, e devo confessarvi che mi sono ricreduto: quasi per magia (il mio collega e amico Dario Airoldi , scherzando, mi ha chiamato Silvan quando ha visto la mia piccola demo :-)), continuavo a rimuovere decine di righe di codice che avevo scritto fino a scendere a zero istruzioni C# e due soli attributi del bottone in XAML, e il programma continuava a funzionare anche meglio di prima (per esempio, potevo evitare di monitorare  lo stato della clipboard con un timer)!

In effetti, riflettendoci bisogna ammettere che è quasi imbarazzante che io spieghi a Windows che quando premo CTRL-V lui deve andare a prendere il contenuto della clipboard e scriverlo nel controllo con il focus: dovrei solo potergli dire incolla! e poi saprà ben lui come fare, non vi pare?

Se vi ho incuriosito a sufficienza, potete guardarvi lo screencast del mio test che ho descritto sopra, che ho registrato in modo amatoriale (dovrete alzare un po' il volume, ed è sicuramente migliorabile) per il mio archivio personale ma che credo possa aiutare nella comprensione di questo argomento.

Vi auguro buona visione. Alla prossima

Per sfruttare al meglio il tempo a disposizione, è necessario preparare i PC in anticipo; si tenga presente che a seconda della configurazione di partenza del PC, della disponibilità del materiale da installare (su DVD o con download dal sito Microsoft), la configurazione può richiedere anche alcune ore; in questo post riassumo le istruzioni, che variano a seconda della tipologia di esercizi da svolgere. In particolare, occorre avere installati:

• Sistema Operativo Microsoft Windows XP SP2 o Windows Vista, aggiornati attraverso il sito windowsupdate.microsoft.com

• Per le esercitazioni su ASP.NET, ADO.NET e Master Pages, scaricare il file HOL.ZIP e seguire istruzioni per la configurazione contenute in questo post o nel file 00-INSTALLAZIONE LABORATORIO.PDF contenuto in HOL.ZIP

• Le esercitazioni su LINQ richiedono come configurazione minima una versione qualunque di Microsoft Visual Studio 2008 (*) installata con i parametri di default, e la presenza sul PC di SQL Server 2005 (versione Express, installata da Visual Studio, oppure un’altra versione commerciale); servono inoltre i seguenti due file:
  • Il database NorthWind, da aggiungere ai database di SQL Server, per gli esercizi di LinQ to Dataset e LinQ to SQL
  • Il file Customers.XML, per gli esercizi di LinQ to XML

• Per le esercitazioni su Sviluppo Mobile, serve avere installati:
  • il software Activesync 4.5 (per Windows XP) o il Centro gestione dispositivi Windows Mobile 6.1 (per Windows Vista) scaricabili dal sito Microsoft
  • la versione Professional di Microsoft Visual Studio 2008 (*)
  • Il file Orders.sdf
  • La cartella Images
  • Componenti facoltativi, solo per testare l’applicazione su ulteriori emulatori:
    • Windows Mobile 6 SDK (professional e standard)
    • Windows Mobile 6 Localized Emulator Images (Professional + Standard italiano)

(*) Le seguenti opzioni sono disponibili per ottenere Microsoft Visual Studio 2008:

• Utilizzare l’account MSDN-AA (Academic Alliance) fornito dall’Università, che consente a tutti gli studenti afferenti del dipartimento che lo ha sottoscritto di accedere gratuitamente al software Microsoft, fra cui tutti i sistemi operativi, i prodotti server e i prodotti di sviluppo, incluso Visual Studio 2008 Professional;
• Scaricare la versione gratuita di valutazione di Visual Studio Professional 2008, completamente funzionante per 3 mesi.