WPF

WPF ed i 0.01 DPI mancanti

Leonardo — Fri, 24 Mar 2023 01:18:53 GMT

Una caratteristica di WPF e' l'indipendenza dalla risoluzione, in particolare le immagini bitmap vengono automaticamente ridimensionate a 96 DPI, valore di default storico di Windows.

Un'immagine 512x512 pixel a 72 DPI verra' quindi ridimensionata a 682.5 x 682.5 pixel circa. Questo succedera' indipendentemente dai DPI impostati nel sistema.

Utilizzando software professionali di editing di immagini come Adobe Photoshop, Gimp, etc.. e' possibile salvare i nostri capolavori con una risoluzione DPI specifica. Questa informazione (DpiX e DpiY) non modifica di fatto la dimensione in pixel dell'immagine, ma e' un attributo che viene salvato nei metadati del file e che puo' essere per esempio utile in fase di stampa... e in WPF.

Soddisfatti della nostra creazione, impostiamo quindi 96 DPI, certi che la nostra immagine non verra' mai e poi mai ridimensionata, ed aggiungiamo il seguente codice XAML alla nostra pagina:

La nostra immagine e' stata inserita in un controllo Viewbox a scopo dimostrativo per evitare ridimensionamenti dovuti a limiti di spazio della Window, selezionando il controllo Image notiamo pero' qualcosa di strano nel pannello delle proprieta' di Visual Studio.

L'immagine e' stata ridimensionata da WPF! Il nostro castello di carte e' cascato dalle fondamenta, manca circa 0.1 pixel per lato!

Questo puo' essere un problema trascurabile dal punto di vista grafico e prestazionale, ma cerchiamo ad ogni modo di capire cosa sta succendo.

Eseguendo il seguente codice C#

scopriamo una triste realta' che stravolgera' presto tutte le nostre certezze. L'immagine e' di fatto a 96.01 DPI!

Adobe e' impazzita? un Easter Eggs di Gimp? Un complotto di Visual Studio?

Vediamo quindi di fare chiarezza, il formato PNG salva la risoluzione in un chunk chiamato Physical pixel dimensions (pHYs) composto da tre campi:

- Pixels per unit, x axis (4 bytes, unsigned integer)
- Pixels per unit, y axis (4 bytes, unsigned integer)
- Unit specifier (1 byte)

dove lo standard definisce come unita' valide solamente il metro o l'unita' indefinita. Il metro e' definito anche dal SI (Sistema Internazionale di unita' di misura), quindi a prima vista ha senso impiegarlo in uno standard al posto dei piedi o di altre unita' meno blasonate.

Utilizzando il metro stiamo quindi parlando di DPM (Dot per Meter). Un DPM equivale a 0.0254 DPI e sfortuna vuola che i campi prevedano solamente valori interi.

3779 DPM equivalgono a circa 95.99 DPI mentre 3780 a circa 96.01 DPI. Non esiste modo di specificare 96 DPI precisi, 0.01 DPI saranno sempre mancanti.

NB: Molti software arrotondano i valori di DPI visualizzati, prestare quindi sempre la massima attenzione.

Questo e' un bel dilemma per WPF, che di default usa proprio 96 DPI per le immagini, anche se a dire il vero non ho visto insurrezioni popolari in questi anni.

Un software utile per analizzare (e modificare) i metadati dei file PNG e' TweakPNG, dove a prima vista i nostri sogni di perfezione DPI-eggianti tornano, per poi svanire all'amara realta' con un doppio click.

NB: Questo problema non affligge il formato TIFF dove l'unita' di risoluzione puo' essere impostata in pollici (inch).

Per motivi di orgoglio piu' che tecnici non vogliamo pero' convertire tutte le nostre icone al formato TIFF, cosa possiamo dunque fare?

La matematica non lascio molto scampo, ma la fantasia ha ancora qualche carta da giocare.

Per risolvere il problema possiamo procedere in due modi:

- cancellare il chunk pHYs (che e' opzionale) se creato dall'app di editing grafico.

- impostare ad "unspecified units" l'unita' di misura. I valori X ed Y verranno ignorati.

Entrambe queste soluzioni forzeranno a 96 DPI esatti la risoluzione dell'immagine in WPF ed eviteranno qualsiasi ridimensionamente.

Personalmente preferisco utilizzare utility come PNGGauntlet che eliminano i chunk opzionali ed ottimizzano la dimensione del file (senza perdita di dati). Molto utile anche per evitare errori "App manifest references .. which is larger than the maximum image file size." durante il packaging di applicazioni UWP.

Avete mai notato che i 96 DPI esatti non esistono nei formati PNG e BMP? Dite la vostra nei commenti ed un saluto a tutti!

NB: Gli stessi concetti posso applicarsi ad altre tecnologie basate su XAML come ad esempio UWP

DependencyProperty e valore di default

Leonardo — Tue, 11 Oct 2011 00: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

DataBinding di specifici oggetti in collezioni

Leonardo — Sat, 22 Jan 2011 00: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 — Sat, 08 Jan 2011 01: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

Scatenare gli eventi del Mouse o della Stilo in un Panel

Leonardo — Tue, 05 Oct 2010 15: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 16: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

WPF e il 3D (ottava parte) – Cubo multi-texture da codice

Leonardo — Fri, 02 Apr 2010 01:54:34 GMT

Indice degli articoli su WPF e il 3D

Nel precedente articolo abbiamo visto come creare un cubo multi-texture (ovvero con materiali diversi su ogni faccia) utilizzando esclusivamente XAML, il risultato era un codice abbastanza prolisso e poco riutilizzabile. Realizziamo ora un componente che sia semplice da utilizzare, alla fine dovremmo poter scrivere solamente il seguente codice XAML:

NB: Per poter aggiungere alle proprietà il supporto al Binding dobbiamo utilizzare nel componente le Dependency Property

Il MultiTexturedCube essendo un oggetto 3D per poter essere visualizzato dovrà essere inserito tra i Children (di tipo Visual3D) di un ViewPort3D, deriviamo quindi da ModelVisual3D il nostro componente.

Il nostro componente avrà necessità di sapere come costruire il cubo quindi dovrà contenere i modelli 3D (GeometryModel3D) delle facce del cubo da visualizzare. I modelli come visto nei precedenti articoli avranno una geometria che sarà inizializzata nel costruttore del componente in modo analogo a come avevamo fatto tramite XAML, ecco un esempio di codice:

Infine per poter essere visualizzati assieme i modelli dovranno essere raggruppati tramite un Model3DGroup che verrà impostato nella proprietà Content del componente, ereditata da ModelVisual3D.

Per poter impostare il materiale da XAML creiamo le varie Dependency Property inserendo come PropertyChangedCallback un evento che modifichi il materiale della corrispondente faccia. Questo “giro” è necessario in quanto tramite Dependency Property non è possibile esporre la proprietà di un altro oggetto (il modello 3D) direttamente.

Il diagramma finale del nostro componente è il seguente:

Riutilizzare il componente è molto semplice, è possibile creare ad esempio un dado derivando da MultiTexturedCube e assegnando nel costruttore i materiali contenenti i numeri del dado, in questo modo non sarà neppure necessario specificare tutti i materiali di volta in volta. Non è difficile neppure estendere il componente, continuando l’esempio del dado è possibile aggiungere la proprietà Numero che una volta impostata applica un’animazione alla proprietà Trasform che ruota il dado con il numero scelto verso l’alto.

Scarica il codice sorgente dell’articolo

NB: Nel codice dell’articolo è presente solamente il codice per una singola faccia ove è analogo per le rimanenti facce.

Visualizzare al volo un array in una griglia

Leonardo — Mon, 22 Feb 2010 01:11:06 GMT

I controlli griglia di Windows Forms (DataGridView) e WPF (DataGrid) non permettono di visualizzare “al volo” correttamente insiemi di elementi di tipi come int, float, string, etc.. perché non espongono il loro valore come una proprietà.

Il seguente codice per esempio

int[] myArray = new int[] { 1, 2, 3 };
dataGrid1.ItemsSource = myArray;

mostrerà solamente una griglia con tre righe vuote.

Una lista di elementi di tipo string invece visualizzerà nella griglia solamente le lunghezze delle stringhe ma non il loro contenuto proprio perché la prima proprietà della classe string è Lenght. Molto spesso però la necessità è di visualizzare l’effettivo testo della stringa.

Per ovviare rapidamente al problema possiamo creare un Extension Method che aggiungerà a tutti gli insiemi enumerabili (di tipo IEnumerable<T>) un metodo chiamato ToPropertyData che ritornerà i valori degli elementi dell’insieme esposti come proprietà di un oggetto contenitore chiamato DataContainer.

Per visualizzare correttamente un array di int sarà necessario solamente scrivere il codice

int[] myArray = new int[] { 1, 2, 3 };
dataGrid1.ItemsSource = myArray.ToPropertyData();

ed il gioco è fatto.

il codice dell’Extension Method:

publicstaticclassExtensionMethodHelper{
    public class DataContainer<T>
    {
        T data;
        public T Data { get { return data; } }
        public DataContainer(T value)
        {
            this.data = value;
        }
    }
    /// <summary>
    /// Convert array of data into array of DataContainer class that expose data as property
    /// </summary>
    /// <remarks>Useful with DataGrid(View)</remarks>
    public static List<DataContainer<TSource>> ToPropertyData<TSource>(this IEnumerable<TSource> source)
    {
        List<DataContainer<TSource>> result = new List<DataContainer<TSource>>();
        foreach (var item in source)
        {
            result.Add(new DataContainer<TSource>(item));
        }
        return result;
    }
}

questo Extension Method è valido solamente per visualizzare i valori in una griglia in modo rapido (ad esempio per controllare determinati valori in fase di debug) ma non supporta la sincronizzazione con l’insieme di origine (nell’esempio l’insieme myArray).

WPF e il 3D (settima parte) – Cubo multi-texture

Leonardo — Fri, 19 Feb 2010 17:32:20 GMT

Indice degli articoli su WPF e il 3D

Nel precedente articolo abbiamo visto come colorare un oggetto 3D ed abbiamo trattato le problematiche di mappatura con oggetti 2D chiamati texture.

In questo articolo prendiamo invece in considerazione l’applicazione di più materiali, uno per faccia, ad un unico modello 3D: in questo caso un cubo che abbiamo già visto come creare.

WPF permette di associare ad ogni GeometryModel3D un solo materiale per la vista frontale ed un solo materiale per la vista di retro, per superare questa limitazione possiamo seguire diverse strade:

- Creare una texture unica formata dall’unione delle varie texture e mappare ogni punto di conseguenza

Esempio di texture unica per creare un effetto multi-texture

Questo stratagemma seppur altamente performante comporta difficoltà nel simulare materiali “dinamici” come ad esempio video o materiali con applicati dei VisualBrush

- Suddividere il modello 3D in tante parti

Questa è la soluzione che offre più flessibilità in quanto rende possibile cambiare singolarmente i vari materiali.

Un esempio di cubo 3D suddiviso in più parti (suddiviso nelle 6 facce) è il seguente:

Come si può notare all’interno di un singolo ModelVisual3D (che dovrà poi essere inserito all’interno di un Viewport3D) è definito un Model3DGroup che contiene i vari pezzi (GeometryModel3D) con applicati diversi materiali. I dati veri e propri sono inseriti all’interno della sezione Resource del ViewPort3D per questioni di compattezza e riutilizzo.

Una parte dei dati del cubo 3D all’interno della sezione Resource del Viewport3D

Questa soluzione comporta però un codice Xaml molto prolisso e poco riutilizzabile, vedremo nel prossimo articolo come creare un componente altamente riutilizzabile ed estendibile ereditando dalla classe ModelVisual3D.

Scarica il codice sorgente dell’articolo

Massimizzare le finestre sopra la Barra delle applicazioni in Windows 7

Leonardo — Fri, 16 Oct 2009 17:00:09 GMT

In Windows XP esisteva nelle Proprietà della barra delle applicazioni e del menù Start un’opzione chiamata Sempre in primo piano che poteva essere deselezionata e permetteva alle applicazioni massimizzate di poter essere davanti anche alla barra delle applicazioni.


Windows Xp	Windows 7

In Windows 7 questa opzione è purtroppo scomparsa ed ora le finestre appaiono tutte inevitabilmente sotto alla trasparenza della barra delle applicazioni:


Windows Xp con l’opzione Sempre in primo piano disabilitata	Windows 7

A volte però si può avere la necessità di ricreare il comportamento disponibile in Windows Xp nella propria applicazione.

Visto che l’opzione non esiste più si può ricorrere ad un piccolo “trucco” chiamando la seguente funzione all’avvio del proprio programma:

Il codice sostanzialmente consiste nell’impostare tramite alcune chiamate di Windows uno stile non in primo piano per la Shell_TrayWnd ovvero la TaskBar o barra delle applicazioni.

La soluzione però non è valida quando la finestra viene massimizzata dall’utente, a differenza di Windows XP infatti le finestre rimangono sopra alla barra delle applicazioni.

Finestre massimizzate in Windows 7, nonostante il codice precedente le finestre massimizzate non copriranno la barra delle applicazioni

Una soluzione migliore e più semplice per estendere a tutto schermo le finestre massimizzate è disabilitare il MaximizeBox.

Impostando a false il MaximizeBox (in applicazioni Windows Forms) e massimizzando da codice con l’istruzione WindowState = FormWindowState.Maximized le finestre appariranno infatti a pieno schermo massimizzate.

Finestra massimizzata via codice in Windows 7 e con la proprietà MaximizeBox = False, la barra delle applicazioni risulta coperta.

Purtroppo con applicazioni WPF non si dispone di una proprietà MaximizeBox ma si può ovviare impostando WindowStyle a None “perdendo” però la barra del titolo dell’applicazione.