Il blog di Leonardo

DependencyProperty e valore di default

Leonardo — Mon, 10 Oct 2011 21:02:04 GMT

Quando si crea una proprietà di dipendenza non si gestisce direttamente il valore di default ma lo si specifica attraverso i metadati. Se la proprietà è un Reference Type il valore di default viene applicato a tutte le istanze del tipo e non alle singole istanze. Questo comportamento è particolarmente critico quando si lavora con delle collezioni.

Per capire meglio questo comportamento e le sue conseguenze consideriamo una semplice applicazione con una finestra contenente due istanze di un UserControl

L'UserControl (chiamato SampleUserControl) possiede una DependencyProperty con dati di tipo Reference come ad esempio il tipo Person.

Codice dell'UserControl (il codice XAML è omesso)

Il valore di default della DependencyProperty è impostato ad una nuova istanza di Person

Il controllo contiene una TextBox collegata tramite databinding (UpdateSourceTrigger=PropertyChanged) alla proprietà Name della proprietà Person del controllo stesso (TextBox.Text <=> UserControl.Person.Name).

Lanciando l'applicazione e iniziando a scrivere sulla TextBox del primo controllo cosa succederà?
Automaticamente anche la seconda TextBox verrà valorizzata con quanto scritto.

Cerchiamo di capire cosa succede:

- Alla creazione della prima istanza del controllo, dato che la proprietà non è valorizzata viene assegnato il valore di default, "una sorta di puntatore" ad un nuovo oggetto Person

- Alla creazione della seconda istanza del controllo la proprietà viene valorizzata con lo stesso puntatore. Entrambi i controlli puntano quindi allo stesso oggetto Person.

- Modificando la prima proprietà verrà modificato l'oggetto Person "puntato" anche dal secondo controllo. La modifica sarà quindi visibile anche dal secondo controllo.

Concludendo il comportamento è a prima vista differente dalle normali aspettative di un programmatore ma consente un notevole risparmio di memoria in controlli con molte proprietà non inizializzate.

Scarica l'applicazione di esempio

Aruba e SMTP

Leonardo — Mon, 09 May 2011 21:04:49 GMT

Inviare la posta da una casella @miodominio.it in hosting presso Aruba tramite un client di posta comporta alcune difficoltà, riporta il sito di aruba la seguente nota:

Attenzione: E' possibile che alcuni fornitori di connessioni internet (ad esempio Tele2, Tre, ecc.. ) NON consentano l'invio dei messaggi da indirizzi legati a domini registrati con Aruba utilizzando smtp.nomedominio.xxx: in questi casi il parametro da inserire potrebbe ad esempio essere smtp.tele2.it e relativa autenticazione oppure smtp.tre.it. Ovviamente per ulteriori dettagli fare riferimento specifico al proprio provider di connessione.

Ma purtroppo non viene data direttamente una soluzione.

Per risolvere il problema alla radice è sufficiente utilizzare il protocollo SSL per inviare (ma è possibile anche per leggere) la propria posta da connessioni come l'adsl di Alice.

I dati da impostare nel proprio account sono:

Server posta in arrivo: pop3s.aruba.it
Server posta in uscita (SMTP): smtps.aruba.it

E' necessario impostare anche altre impostazioni:

Spuntare "Il server della posta in uscita (SMTP) richiede l'autenticazione" e selezionare "Utilizza le stesse impostazioni del server della posta in arrivo"

Nella scheda Impostazioni avanzate è necessario impostare la porta POP3 a 995, selezionare "Il server richiede una connessione crittografata (SSL)", impostare la porta SMTP a 465 e selezionare dal menù a discesa SSL come tipo di connessione crittografata.

Buona lettura della posta dal vostro client di posta preferito

Da testo a string in C#

Leonardo — Fri, 15 Apr 2011 16:56:44 GMT

Durante il test di alcune classi che elaborano file XML ho avuto la necessità di convertire diversi file XML in stringhe C# per evitare di avere dipendenze da file esterni.

Diciamo che convertire del testo in stringhe C# è un'operazione abbastanza noiosa perché comprende l'aggiunta di doppi apici per ogni riga e di slash aggiuntive, '\' diventa '\\' a meno di usare la keyword @.

Ho quindi creato una piccola utility che permette di svolgere in modo rapido questa operazione, se vi serve potete scaricarla assieme al sorgente per adattare meglio il programma alle vostre esigenze

Scarica "Paste Text as C# String"

Riconoscimento della scrittura in Windows Forms

Leonardo — Tue, 25 Jan 2011 14:41:06 GMT

Una novità passata perlopiù dietro le quinte di Windows 7 (HomePremium e versioni superiori) è l'inclusione dell'Assembly Microsoft.Ink (versione 6.1) nella GAC. Prima era necessario installare l'SDK dedicato e distribuire assieme alla propria applicazione le relative librerie.

Questo Assembly permette di utilizzare in applicazioni Windows Forms due nuovi controlli per supportare la scrittura ed il riconoscimento della calligrafia in maniera molto semplice: InkEdit ed InkPicture
Rimando all'articolo Add Support for Digital Ink to Your Windows Applications per una descrizione dell'uso di Microsoft.Ink e delle sue classi e controlli, anche se l'articolo fa riferimento alla versione dell'SDK e non a quella shippata con Windows 7, l'utilizzo è analogo.

Purtroppo l'Assembly non include controlli per WPF e quindi se si vuole utilizzare il riconoscimento automatico della scrittura in WPF la strada più semplice rimane installare l'SDK dedicato allo sviluppo per Tablet PC.

Per poter iniziare a utilizzare questo Assembly ho trovato molto utile l'Addin Muse per Visual Studio 2010 che permette di visualizzare e filtrare gli Assembly nella GAC. Ricordo che per Visual Studio normalmente non mostra tutti gli Assembly della GAC ma solamente un sottoinsieme contenuto in C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0

Una volta aggiunto il riferimento alla versione 6.1.0 di Microsoft.Ink sarà sufficiente scegliere Choose Items.. tramite tasto destro sulla barra degli strumenti e tramite Sfoglia cercare C:\Windows\assembly\GAC_32\Microsoft.Ink\6.1.0.0__31bf3856ad364e35\Microsoft.Ink.dll (per la versione a 32 bit) ovvero il percorso fisico dell'Assembly.

Troveremo ora nella nostra casella degli strumenti i due nuovi controlli e trascinando il controllo InkEdit sul nostro forms avremo un RichEditControl evoluto che riconoscerà in automatico evenutuali scritte a mano (bisogna avere una tavoletta grafica o una schermo touch per poter scrivere sul controllo) e le convertirà senza scrivere una riga di codice in testo dopo qualche istante.

DataBinding di specifici oggetti in collezioni

Leonardo — Fri, 21 Jan 2011 22:47:01 GMT

Il DataBinding in WPF è sicuramente un elemento essenziale ed un primo cittadino ma supponiamo di avere una collezione generica come ObservableCollection<T>, dove T è una nostra classe, per esempio la classica classe Person contenente le proprietà Nome, Cognome e Descrizione: come facciamo a visualizzare tramite XAML nella nostra finestra la descrizione di Mario Rossi?

Diagramma della classe Person

Questo scenario non è direttamente supportato in quanto la sintassi di Binding permette di specificare proprietà, sottoproprietà ed indicizzatori ma non selezionare oggetti in collezioni dato il valore di alcune loro proprietà.

NON è possibile per esempio scrivere, supponendo come contesto dei dati la collezione (DataContext=Collezione), codice XAML di questo tipo

per selezionare la descrizione dell'oggetto della collezione che ha come valore della proprietà Name "Mario" e come valore della proprietà SurName il valore "Rossi".

Vediamo come risolvere questo problema:

Per semplicità ci limiteremo a supportare la selezione della proprietà ToString che nel caso della classe Person restituirà esattamente "Name Surname".

Potremmo cioè poter scrivere

<TextBlock Text="{Binding Path='Mario Rossi.Description'}" />
ma nulla vieta di estendere questo esempio per supportare una sintassi "XPath o Linq Like".

Ricapitolando il DataBinding viene effettuato su Proprietà, dobbiamo perciò far credere al motore di DataBinding di WPF che la nostra collezione espone una proprietà "Nome Cognome" che restituisce il nostro oggetto Person selezionato.

Questo problema è risolvibile estendendo tramite l'ereditarietà la classe ObservableCollection<T> e implementando l'interfaccia ICustomTypeDescriptor che per l'appunto permette di fornire informazioni dinamiche di tipo personalizzato come ad esempio le proprietà che espone una classe.

Se la nostra classe non espone questa interfaccia il motore di DataBinding utilizzerà la Reflection per capire quali proprietà sono disponibili.

NOTA BENE: La Reflection è relativamente lenta e sebbene possano essere utilizzati internamente dei meccanismi di caching, per velocizzare questa operazione sono nati progetti come HyperDescriptor.

L'interfaccia ICustomTypeDescriptor non è tra le più snelle del Framework ed infatti contiene 12 metodi ed è in genere preferibile derivare dalla classe CustomTypeDescriptor ed effettuare solamente gli override di nostro interesse ma purtroppo la nostra ereditarietà è già stata "bruciata" con ObservableCollection<T> e la nostra scelta deve ricadere obbligatoriamente sull'interfaccia.

Anche se a prima vista questa interfaccia potrebbe intimorire a noi interessa veramente solo il metodo GetProperties, possiamo quindi limitarci nell'implementazione degli altri metodi a ritornare i valori di default.

NOTA BENE: Per migliorare le prestazioni possiamo implementare un sistema di caching

Il metodo GetProperties dell'interfaccia ICustomTypeDescriptor serve proprio a ritornare al Framework una collezione di proprietà, basterà quindi eseguire un ciclo su tutti gli elementi della collezione e ritornare per ogni elemento una proprietà chiamata con il metodo ToString dell'oggetto e che contenga come valore l'oggetto stesso.

Esempio di implementazione di GetProperties

Le proprietà sono rappresentate dalla classe astratta PropertyDescriptor, creiamo dunque una classe generica GenericPropertyDescriptor<T> derivante da tale classe con un semplice costruttore che accetta in ingresso un oggetto T e che tramite gli override ad GetValue ed SetValue restituisce ed imposta il valore dell'oggetto. Per impostare il nome della proprietà la classe dovrà chiamare il costruttore della classe base passandogli in questo caso la stringa ritornata dal metodo ToString dell'oggetto.

NOTA BENE: In uno scenario più flessibile probabilmente vorremmo poter passare una funzione agente sull'oggetto per determinare il nome della proprietà
ATTENZIONE: Il nome della proprietà non dovrebbe contenere caratteri come il punto che sono interpretati come sottoproprietà dal motore di DataBinding di WPF

La classe astratta PropertyDescriptor definisce anche altre proprietà e metodi astratti che possiamo però semplicemente implementare con valori di default visto che l'importante è che la proprietà restituisca, imposti e si chiami in un certo modo. Rimando all'analisi del codice allegato per i dettagli.

Diagramma della classe GenericPropertyDescriptor<T>

Il gioco è quasi ultimato, creiamo ora per provare le nostre classi una Window con impostata essa stessa come DataContext e con esposta tramite una proprietà la nostra ObservablePropertyCollection<Person> popolata con alcune persone di esempio.

Nelllo XAML corrispettivo aggiungiamo uno StackPanel che visualizzi tramite TextBlock le varie proprietà dell'elemento Mario Rossi

E il gioco è fatto. Lo XAML risulta immediatamente intuitivo anche se a Design-Time purtroppo non visualizzerà alcun risultato.

Nel codice allegato è presente inoltre un pulsante che dimostra come la soluzione proposta, a differenza di soluzioni a base di Converter, supporta la notifica delle singole proprietà dell'elemento selezionato.

Codice Allegato

Missione completata

Sincronizziamo le animazioni con WPF

Leonardo — Fri, 07 Jan 2011 23:00:00 GMT

WPF offre un gran supporto alle applicazioni che vogliono utilizzare animazioni. Tramite poche righe di Xaml possiamo dire agevolmente che vogliamo animare la proprietà di riempimento di un oggetto da un colore ad un altro in un certo periodo di tempo infinite volte utilizzando perfino delle funzioni matematiche per variare non linearmente l'animazione.

Esempio di animazione di un colore in Xaml

Non è però previsto un modo per aggiungere animazioni in maniera sincronizzata a quelle già esecuzione.

Se iniziamo un'animazione che sfuma dal bianco al rosso un ellisse e, supponiamo a metà dell'animazione, vogliamo iniziare un'altra animazione su un altro oggetto ma allo stesso tempo vogliamo tenere allineate temporalmente le due animazioni come possiamo fare?

Altri esempi di utilizzo possono essere led che lampeggiano continuamente in sincronia nella nostra animazione al cambiamento di determinate proprietà o eventi.

La tecnica più semplice se non ci preoccupa il fatto di dover fermare a metà le animazioni in esecuzione, è fermare le animazioni in corso e riiniziarle con la nuova.

Eseguire queste operazioni può significare scrivere tanto codice ogni volta ma vediamo come creare un TriggerAction che ci permette di incapsulare questa funzionalità e renderla riutilizzabile e fruibile da Xaml.

In sostanza animare la proprietà Fill di un ellisse diventerà facile come scrivere:

Dove il namespace "i" si riferisce al namespace Interactive aggiunto da Expression Blend ma che verrà molto probabilmente incluso ufficialmente nel framework nella prossima versione.

Sono stati utilizzati gli Interactive Trigger di Expression Blend e quindi è necessario aggiungere al progetto la Reference a System.Windows.Interactive e copiare la relativa .dll assieme all'exe (avviene in automatico dopo aver aggiunto la Reference) perchè a differenza di quelli inclusi nella versione attuale del Framework permettono una maggiore estendibilità ed aprono quindi nuovi scenari come quello descritto in questo articolo.

Ancora meglio possiamo addirittura fare drag-and-drop da Expression Blend del nostro TriggerAction dagli Asset di tipo Behaviors sul nostro oggetto e settare poco più di un paio di proprietà nella scheda Miscellaneous.

Vediamo ora come creare la nostra classe che chiameremo SyncAnimationAction.

Innanzitutto dovremo derivare SyncAnimationAction da System.Windows.Interactivity.TriggerAction<DependencyObject> per poter essere richiamata senza scrivere codice da ulteriori Interaction Trigger.

I Trigger possono scatenare l'animazione sincronizzata quando cambia una proprietà (PropertyChangedTrigger), allo scatenarsi di un evento (EventTrigger), alla pressione di un pulsante (KeyTrigger), etc..

Aggiungiamo quindi alla nostra classe 4 Proprietà che potranno essere impostate dallo Xaml come visto prima:

Proprietà	Tipo	Descrizione
Animation	AnimationTimeline	L'animazione da eseguire
AnimatedObject	IAnimatable	L'oggetto su cui eseguire l'animazione
AnimatedProperty	DependencyProperty	La proprietà dell'oggetto da animare
AnimationStopped	bool	Flag che indica se l'animazione è da terminare

Le prime 3 proprietà (o anche AnimationStopped se si ha la necessità) dovranno essere DependencyProperty per supportare il Binding tramite XAML.

Effettuiamo poi l'override del metodo Invoke che verrà scatenato dai Trigger ed aggiungiamo poi tramite una classe "contenitore" AppliedAnimation i nostri valori ad una variabile List<AppliedAnimation> statica chiamata _animations.

Quando verrà chiamato Invoke la nostra classe avrà già popolate le proprietà (AnimatedObject, AnimatedProperty, Animation e AnimationStopped) da Xaml quindi dovremo solamente controllare che questi dati siano validi per poterli aggiungere alla lista.

La lista servirà per tenere dei riferimenti alle nostre animazioni e ci permetterà di fermare/riavviare tutte le animazioni nella lista all'aggiunta di una nuova animazione.

All'aggiunta di una nuova animazione scorreremo tutta la lista delle animazioni fermandole e facendole ripartire.

Per gestire le animazioni non ci serviremo della classe Storyboard in quanto trova la sua maggiore utilità nel codice XAML ma semplicemente utilizzeremo il metodo BeginAnimation passando rispettivamente prima il secondo parametro nullo e poi con l'animazione da eseguire.

Eviteremo quindi l'overhead dovuto ad instanziare un ulteriore StoryBoard.

Spostiamo dunque il codice di sincronizzazione vero e proprio in un metodo statico ReSync per poterlo chiamare eventualmente anche da codice C# (o VB.NET).

Come facciamo però a rimuovere un'animazione?

Qui entra in gioco la quarta proprietà AnimationStopped, semplicemente nel metodo Invoke dovremo controllare se l'animazione è già presenta in lista e in tal caso fermarla ed eliminarla.

Memory Leak?

Mantenendo un riferimento agli oggetti IAnimatable nella lista tramite un AppliedAnimation potremmo causare un memory leak, è quindi consigliabile utilizzare la classe WeakReference al posto del tipo IAnimatable nella lista perché così il Garbage Collector potrà cancellare gli oggetti se sono rimasti solamente nella nostra lista.

E se aggiungo molte animazioni?

Se si aggiungono tante animazioni, ad ogni animazione aggiunta vengono riavviate le precedenti e questo potrebbe causare qualche problema prestazionale se le animazioni sono complesse e se sono in gran numero.

Esempio: se aggiungo 100 animazioni avrò 100 ReSync che complessivamente riavvieranno 100+99+98+....+1 animazioni e questo potrebbe non essere desiderato, è quindi necessario inserire una proprietà che permetta di "saltare" il metodo ReSync fino a quando tutte le animazioni non saranno state aggiunte. In questo modo si potrà avere un solo ReSync alla fine dell'aggiunta in blocco delle animazioni.

Nel codice allegato è presente l'implementazione comprensiva di WeakReference

NHibernate 3.0 RTM e Medium Trust

Leonardo — Thu, 09 Dec 2010 19:35:19 GMT

Update 18/05/2011: Scarica la versione di NHibernate-3.1.0.GA compilata con LinFu-1.0.3.28303 compatibile con Medium Trust (leggere comunque il resto l'articolo per modificare il file di configurazione)

NHibernate 3.0 è finalmente stato rilasciato in versione finale ma purtroppo presenta qualche problema con hosting Medium Trust (e quindi i siti in hosting su Aruba), vediamo come ricompilare il nostro ORM per renderlo finalmente funzionante anche in tali condizioni.

Premetto che non dobbiamo modificare il sorgente di NHibernate ma semplicemente ricompilarlo con le nuove versioni delle librerie LinFu e RemotionRelinq.

Scarichiamo:
- i sorgenti di NHibernate 3.0GA
- LinFu.DynamicProxy 1.031
- RemotionRelinq 1.13.84 (o comunque una versione successiva alla 1.13.63, le versioni con l’ultimo numero pari sono più stabili)
- NAnt 0.90 ci servirà per compilare il tutto

Come primo passo scompattiamo i sorgenti di NHibernate e al loro interno scompattiamo NAnt che sarà quindi contenuto dentro alla cartella nant-0.90.
Creiamo ora il file “Build.bat” che ci permetterà di compilare tramite NAnt col seguente contenuto:

@nant-0.90\bin\NAnt.exe -t:net-3.5 -D:project.config=release clean package
pause

Prima di lanciare la compilazione però andiamo a copiare nella cartella lib/net/3.5 dei sorgenti di NHibernate il file LinFu.DynamicProxy.dll contenuto nel secondo download e il file Remotion.Data.Linq.dll contenuto nella cartella net-3.5/bin/release del terzo download.

Lanciamo adesso il file Build.bat creato in precedenza e aspettando qualche secondo troveremo la cartella build che conterrà al suo interno il nostro NHibernate pronto per essere utilizzato in ambienti Medium Trust.

NB: La compilazione della documentazione potrebbe fallire ma ciò non influisce sulla compilazione delle dll.

Per poter utilizzare NHibernate in ambienti Medium Trust nel file di configurazione App.config dobbiamo ricordarci di specificare requirePermission="false" nelle sezioni di configurazione di NHibernate e Log4Net. Esempio:

<configuration>
    <configSections>
        <section name="hibernate-configuration" type="NHibernate.Cfg.ConfigurationSectionHandler, NHibernate" requirePermission="false"/>
        <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" requirePermission="false"/>
    </configSections>
...

Mentre nella hibernate-configuration dobbiamo specificare reflection-optimizer use="false" e come proxyfactory Linfu

<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
    <reflection-optimizer use="false"/>
    <session-factory>
        ...
        <property name="proxyfactory.factory_class">NHibernate.ByteCode.LinFu.ProxyFactoryFactory, NHibernate.ByteCode.LinFu</property>
        ...
    </session-factory>
</hibernate-configuration>

That’s all!

Voglio infine ringraziare Padova Boy per l'eccellente articolo su come utilizzare NHibernate 2.1.2 in ambienti Medium Trust.

Scatenare gli eventi del Mouse o della Stilo in un Panel

Leonardo — Tue, 05 Oct 2010 12:39:00 GMT

Controlli Panel come Grid, StackPanel, Canvas e DockPanel (ma anche altri) ereditano una serie di eventi del Mouse e della Stilo da UIElement come MouseDown, MouseUp, etc.. che però in genere non ricevono (vengono ricevuti solamente dagli elementi figli tramite il bubbling o il tunneling).

Ad esempio il seguente codice XAML con la relativa funzione

non scatenerà mai l’evento e di conseguenza la MessageBox alla pressione del mouse.

La documentazione della Grid purtroppo non ci è di grande aiuto per risolvere la situazione ma all’interno della documentazione della classe base Panel troviamo la risposta:

Gli elementi Panel non ricevono eventi del mouse o dello stilo se non viene definito un Background.Se è necessario gestire eventi del mouse o dello stilo ma non si desidera uno sfondo per Panel, utilizzare Transparent.

Seguendo le istruzioni e inserendo un Background Transparent possiamo quindi abilitare la ricezione dei suddetti eventi e a far apparire il nostro messaggio.

NB: Anche impostando Visibility a Collapsed vengono soppressi tali eventi

Grafici con WPF e LINQ

Leonardo — Tue, 17 Aug 2010 13:26:19 GMT

Aggiornato l’articolo su come creare grafici partendo da zero tramite WPF e LINQ per includere alcune nuove peculiarità del .NET Framework 4.0.

Testo più chiaro con TextOptions.TextFormattingMode="Display"

Grafici più definiti con UseLayoutRounding (precedentemente veniva disabilitato solamente l’Anti-Aliasing dei bordi)

Progetto scaricabile in formato Visual Studio 2010

Leggi l’articolo aggiornato al 17/08/2010

NHibernate 3

Leonardo — Thu, 29 Jul 2010 23:14:59 GMT

NHibernate, famoso ORM per .NET ha raggiunto lo stadio UPDATE: RTM per la terza release.

Tante le novità, quelle che ho trovato personalmente più utili sono la compatibilità con l’esecuzione Medium Trust in applicazioni web ASP.NET (niente più ricompilazioni con modifiche apposite ad ogni nuova versione, evviva!) ed un nuovo supporto a LINQ totalmente riscritto per una maggiore flessibilità.

UPDATE: Purtroppo Medium Trust è supportato completamente in NHibernate.dll ma non in alcune librerie distribuite assieme alla versione finale. Per risolvere il problema leggere l'articolo NHibernate 3 e Medium Trust

Le modifiche da apportare per provare il supporto a LINQ della nuova versione sono solamente il cambio di un paio di righe di codice:

NHibernate 2.x

NHibernate 3.x

Il nuovo supporto rende inoltre possibile scrivere query come:

Verrà prodotta in automatico la query SELECT * FROM Events WHERE YEAR(Date)=2009

NB: La query è stata abbreviata sostituendo tutti i nomi dei campi con l’asterisco e inserendo direttamente l’anno che in realtà viene passato come parametro per renderla più corta e leggibile in questo articolo.

Fino alla versione 2.x scrivere una query equivalente richiedeva l’utilizzo di codice SQL (nativo o tramite ICriteria) o HSQL.

Potete scaricare questa nuova versione all’indirizzo http://sourceforge.net/projects/nhibernate