WPF

Utilizzare l’interfaccia Metro su un’applicazione WPF

Martino Bordin — Mon, 11 Jun 2012 17:00:55 GMT

Se negli ultimi anni non avete vissuto su Marte, avrete sicuramente sentito parlare dell’interfaccia Metro (per i marziani, ecco un link che vi spiega velocemente cos’è ).

Nel caso stiate sviluppando applicazioni per Windows Phone o Windows 8 (le famose Metro App), avrete già tutti i controlli disponibili che seguono questo stile, senza dover adottare alcun accorgimento particolare..

E nel caso di applicazioni WPF?

Bhè, esiste il toolkit di Mahapps, che ci omaggia di una serie di controlli, stili, behaviors e attached properties che fanno proprio al caso nostro!

Come potete vedere il risultato è notevole, e senza particolari stravolgimenti del nostro Xaml:

Metro is everywhere!

P.S: Anche per il web sono disponibile progetti interessanti (es link1 , link2)

Merge di DLL in un’applicazione WPF

Martino Bordin — Thu, 05 Apr 2012 15:07:51 GMT

Recentemente ho dovuto creare un’applicazione WPF che fosse facilmente distribuibile (leggi: distribuire solo l’exe).

Purtroppo il tool ILMerge non funziona per applicazioni WPF, a causa di problemi con le risorse contenute in esse (esistono comunque tool funzionanti di terze parti, a pagamento).

Seguendo questo post, ho creato un esempio che qui illustro e che potete scaricare qui.

L’applicazione visualizza semplicemente il fullname di due classi presenti in 2 assembly referenziati:

Per prima cosa è necessario modificare il file di progetto dell’applicazione WPF aggiungendo, dopo “Microsoft.CSharp.targets” , il seguente snippet:

 <Target Name="AfterResolveReferences">
    <ItemGroup>
      <EmbeddedResource Include="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.Extension)' == '.dll'">
        <LogicalName>%(ReferenceCopyLocalPaths.DestinationSubDirectory)%(ReferenceCopyLocalPaths.Filename)%(ReferenceCopyLocalPaths.Extension)</LogicalName>
      </EmbeddedResource>
    </ItemGroup>
  </Target>
 

Semplicemente, andiamo ad indicare di inserire tutti i file referenziati con estensione “.dll” come “emdedded resource” nell’exe principale. In questo modo eviteremo di eseguire a mano l’inclusione dell’ultima versione delle librerie compilate.

Nelle proprietà del progetto, impostiamo il seguente comando da eseguire durante la fase di post-build: “del $(TargetDir)*.dll” per cancellare tutte le librerie presenti nella “bin”, che non ci serviranno più...

Impostiamo quindi come oggetto di avvio la classe Bootstrapper (potete ovviamente cambiare il nome):

Questa, infine, è come definita la classe BootStrapper:

 public class BootStrapper
{
    [STAThread]
    public static void Main(string[] args)
    {
        AppDomain.CurrentDomain.AssemblyResolve += OnResolveAssembly;
        App.Main();
    }
 
    private static Assembly OnResolveAssembly(object sender, ResolveEventArgs args)
    {
        var executingAssembly = Assembly.GetExecutingAssembly();
        var assemblyName = new AssemblyName(args.Name);
 
        string path = string.Format("{0}.dll", assemblyName.Name);
        if (assemblyName.CultureInfo.Equals(CultureInfo.InvariantCulture) == false)
        {
            path = string.Format(@"{0}\\cf4 {1}", assemblyName.CultureInfo, path);
        }
 
        using (var stream = executingAssembly.GetManifestResourceStream(path))
        {
            if (stream == null)
            {
                return null;
            }
 
            var assemblyRawBytes = new byte[stream.Length];
            stream.Read(assemblyRawBytes, 0, assemblyRawBytes.Length);
            return Assembly.Load(assemblyRawBytes);
        }
    }
}
 

Sostanzialmente ci agganciamo all’evento AssemblyResolve dell’AppDomain corrente, che viene sollevato ogni volta che la risoluzione di un’assembly fallisce, e ritorniamo l’assembly che abbia in canna nelle embedded resources.

Ecco infatti come si presenta il nostro exe “aprendolo” con ILSpy:

E’ anche più semplice di usare la riga di comando di ILMerge !

Listbox WPF: disabilitata ma non troppo!

Martino Bordin — Tue, 03 Apr 2012 14:55:30 GMT

Recentemente ho dovuto realizzare una sorta di wizard in WPF, ovvero una classica window con un’intestazione, una listbox a sinistra che visualizza gli step (evidenziando lo step corrente) e un contentpresenter in cui verrà caricato il contenuto dinamicamente. Niente di complicato.

La cosa “particolare” è il fatto che la listbox con l’elenco degli step è read-only, ovvero deve solo presentare i dati e l’utente non deve poter selezionare qual’è lo step corrente..altrimenti che procedura guidata è? .

Ovviamente è possibile disabilitare la listbox , ma in questo modo lo stile applicato rende il tutto poco usabile e gradevole (un grigio che mina la leggibilità del controllo )..e di certo non mi andava di rifare il template del controllo per questa sciocchezza.

Ho risolto semplicemente creando uno style per l’ItemContainer e impostando a false la proprietà Focusable:

<ListBox.ItemContainerStyle>
                <Style TargetType="{x:Type ListBoxItem}">
                    <Setter Property="Focusable" Value="False"/>
                    <Style.Triggers>
                        <Trigger Property="IsSelected" Value="True">
                            <Setter Property="FontWeight" Value="Bold" />
                        </Trigger>
                    </Style.Triggers>
                </Style>
            </ListBox.ItemContainerStyle>

Thanks WPF!

Automapper : creare Dto da proxy Nhibernate

Martino Bordin — Wed, 29 Feb 2012 01:00:00 GMT

Se utilizzate AutoMapper per creare Dto da oggetti letti con Nhibernate e lazy-loading attivo, è possibile che otteniate un’eccezione di tipo ObjectDisposedException, in quanto Automapper accede a proprietà “Lazy”, ma la sessione è già stata chiusa e distrutta.

Per risolverlo, basta implementare un Custom Resolver, che tornerà null qualora il tipo della proprietà che sto provando a mappare sia un proxy non inizializzato.

Ecco quindi il codice:

 public class NhProxyResolver : ValueResolver<object, object>
{
    protected override object ResolveCore(object source)
    {
        return NHibernateUtil.IsInitialized(source) ? source : null;
    }
}
 

ed un esempio della configurazione di AutoMapper:

 Mapper.CreateMap<User, UserDto>()
    .ForMember(x => x.Orders, opt => opt.ResolveUsing<NhProxyResolver>().FromMember(z => z.Orders));
 

Automapper : da Dto a ViewModel

Martino Bordin — Sat, 03 Dec 2011 14:59:29 GMT

Ultimamente, in una applicazione WPF, sto utilizzando pesantemente Automapper per convertire dei DTO, ritornati da un servizio , in ViewModel.

Per chi non lo conoscesse questa libreria permette di mappare, in base a convenzioni, un oggetto in un altro .

Detto cosi sembra banale e quasi inutile, in realtà se leggete la documentazione e fate qualche test capirete che offre un sacco di funzionalità e vi tornerà utile in moltissimi casi, tra cui quello che da il titolo a questo post.

Inoltre, essendo estramemente versatile, possiamo anche creare regole custom per mappare gli oggetti o definire eccezioni in questo modo:

Mapper.CreateMap<PersonDto, PersonViewModel>()
    .ForMember(x => x.HasError, opt => opt.Ignore());

Per facilitarmi il lavoro quotidiano, ho scritto un’extension method che indica ad Automapper di ignorare tutte le proprietà di tipo ICommand, in maniera tale da non sollevare eccezioni in fase di verifica delle mappature (operazione effettuata con il metodo Mapper.AssertConfigurationIsValid()).

Ecco quindi il codice, abbastanza intuitivo:

public static class AutoMapperExtensions
{
    public static IMappingExpression<TSource, TDestination> IgnoreAllICommand<TSource, TDestination>(this IMappingExpression<TSource, TDestination> expression)
    {
        const BindingFlags PublicInstanceFlags = BindingFlags.Public | BindingFlags.Instance;
        var destinationProperties = typeof(TDestination).GetProperties(PublicInstanceFlags);
 
        foreach (var property in destinationProperties)
        {
            if (property.PropertyType == typeof(ICommand))
            {
                expression.ForMember(property.Name, opt => opt.Ignore());
            }
        }
 
        return expression;
    }
}

Per utilizzarlo invece:

Mapper.CreateMap<PersonDto, PersonViewModel>()
    .IgnoreAllICommand()
    .ForMember(x => x.HasError, opt => opt.Ignore());

In questo modo non devo “dire” ad AutoMapper di ignorare i vari Command dei ViewModel singolarmente .

Blendability con Moq e NBuilder

Martino Bordin — Tue, 09 Aug 2011 15:59:27 GMT

Che il vostro progetto sia sviluppato in WPF, Silverlight o Silverlight per WP7 un aspetto fondamentale (direi quasi un requisito non funzionale) da soddisfare è il supporto ai designer di Visual Studio/Blend, identificato con il termine “Blendability”.

Anche se può sembrare banale, in realtà la faccenda si complica man mano che i nostri ViewModel prendono forma e utilizziamo IoC.

In soldoni il Designer non è in grado di rappresentare graficamente una View collegata ad un ViewModel di questo tipo:

 public MainViewModel(IPersonService personService)
{
    People = new ObservableCollection<Person>(personService.GetAll());
 
    ShowPersonDetailCommand = new RelayCommand(PerformShowPersonDetail, CanShowPersonDetail);
}
 

Tra le soluzioni possibili troviamo:

utilizzare un ViewModelLocator che restituisce istanze diverse dei ViewModel se siamo a design-time o a run-time (es: link)
utilizzare ViewModel che si comportano in modo diverso se siamo a design-time o a run-time (es: link)
utilizzare file XAML in cui definire i dati fake (es: link)

Personalmente, anche se funzionanti, non mi piace nessuna delle soluzioni proposte in quanto:

vado ad inserire logica completamente estranea ai ViewModelLocator\ViewModel (punti 1, 2)
mi ritrovo a manutenere file XAML satelliti che andranno ad appesantire il refactoring (punto 3)

Da un po' di tempo a questa parte sto adottando la strategia che da il titolo a questo post: uso Moq e NBuilder.

Per chi non li conoscesse, sono 2 librerie che facilitano la scrittura di test automatici, essendo rispettivamente un framework di mocking e un tool per la generazione dinamica di oggetti.

Nonostante siano strumenti nati per altri scopi, ho deciso di provarli per ottenere ViewModel “blendabili”.

In pratica:

Vado a creare, possibilmente in un assembly a parte, un MainViewModelDesign che eredita dal MainViewModel visto in precedenza.

 public class MainViewModelDesign : MainViewModel
{
    public MainViewModelDesign()
        : base(GetMockedService())
    {
    }
}
 

Il Metodo GetMockedService mi ritorna un mock che implementa IPersonService e va a definire i metodi utilizzati dal ViewModel in questione. In questo caso ho instrumentato Moq in maniera tale che, quando viene invocato il metodo GetAll, mi restituisca, tramite la classe Builder di NBuilder, un elenco di Person.

 private static IPersonService GetMockedService()
{
    var mockedService = new Mock<IPersonService>();
    mockedService
        .Setup(s => s.GetAll())
        .Returns(Builder<Person>.CreateListOfSize(5).Build());
 
 
    return mockedService.Object;
}
 

Per collegare il nostro nuovo ViewModel useremo il Databinding e la proprietà d: DataContext, utilizzando la markup extension {d: DesignInstance} (maggiori info qui), passando il nome del ViewModel che vogliamo venga creato automaticamente dal designer (riga 12):

 <Window 
    x:Class="Blendability.Views.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:viewModels="clr-namespace:Blendability.ViewModels.Design"
    Title="People" 
    Height="350" 
    Width="525"
    mc:Ignorable="d"
    d:DataContext="{d:DesignInstance viewModels:MainViewModelDesign, IsDesignTimeCreatable=True}" 
    DataContext="{Binding Source={StaticResource locator}, Path=MainViewModel}">
 

Ovviamente possiamo ancora impostare la “solita” proprietà DataContext che verrà effettivamente utilizzata a runtime (riga 13).

A questo punto se apro Visual Studio o Blend avrò pieno supporto del designer:

Riassumendo:

ho definito un ViewModel che eredita dal ViewModel reale, e si preoccupa solo di visualizzare i dati (e che andrò a mettere su un assembly a parte) ed eventuale logica di generazione dei dati fake (tra l’altro NBuilder è abbastanza versatile e posso definire regole del tipo “le prime 5 Person devono avere Name = “Nome123abc” e DateOfBirth = “01/02/2003”, le restanti Name = “blablabla")
se farò refactoring non dovrò cambiare file XAML se non la View vera e propria
ho il pieno supporto dei designer: editing di stili\template con preview instantanea, animazioni, property window, etc
funziona per progetti WPF\ SL e WP7!

Ho preparato un esempio un pò più articolato di quello illustrato che potete scaricare qui. Ovviamente tutto quello che vedrete aprendo il designer NON lo vedrete a runtime .

Cosa ne pensate? Come ottenete la blendability di solito nei vostri progetti?

Uno snippet per i routed event

Martino Bordin — Thu, 19 Aug 2010 19:18:40 GMT

Come sapete i routed events sono, assieme alle dependency properties, 2 features molto importanti di WPF, fondamentali se dovete sviluppare Custom Control.
Purtroppo la sintassi per dichiararli ed inizializzarli non è esattamente 'straightforward'.

Grazie agli snippet di Visual Studio dichiarare una DependencyProperty è un gioco da ragazzi..stranamente però non esiste uno snippet per i Routed Events.

Poco male, potete scaricare lo snippet per i routed event qui

Multibinding e StringFormat

Martino Bordin — Thu, 19 Aug 2010 19:11:31 GMT

Dalla versione 3.5 SP1 del framework .NET è possibile utilizzare una nuova funzionalità detta MultiBinding.

In che cosa consiste?

Bhè, vi sarà capitato di dover visualizzare a video, magari tramite il controllo TextBlock, informazioni contenute in proprietà distinte della vostro origine dati (ovvero proprietà del ViewModel).

Invece di utilizzare TextBlock, annidate dentro ad uno StackPanel, distinte collegate ad ogni singola proprietà potrete usare questo markup:

Mediante la proprietà StringFormat potete controllare come viene formattata la stringa, e utilizzando gli oggetti Binding potete visualizzare tutte le proprietà che volete..comodo vero?
Ovviamente si possono utilizzare le canoniche FormatString .NET (es: {0:c}, {1:d}).

Da notare le 2 parentesi graffe all'inizio della StringFormat...sono necessari per evitare che il compilatore si arrabbi cercando di interpretare le istruzioni come MarkupExtension.

Alla prossima!