Nota del revisore tecnico
Come il precedente ed i successivi, questo articolo è una traduzione della serie dei Getting Started di Windows Presentation foundation che si trovano su MSDN. Indicherò i link agli articoli originali in inglese e i link correlati saranno tutti alla versione inglese, fatto salvo che, man mano che tradurremo gli articoli più interessanti agganceremo anche la versione in italiano. I link agli articoli saranno effettuati con i due segnalini standard:  che porterà alla versione originale inglese. che porterà alla versione italiana quando questa sarà scritta.
Panoramica degli elementi base di WPF Un'alta percentuale delle classi di Windows Presentation Foundation (WPF) sono derivate da quattro classi che nella documentazione vengono comunemente definite come le classi degli elementi base. - UIElement
- FrameworkElement
- ContentElement
- FrameworkContentElement
Il presente articolo contiene i seguenti argomenti: - API degli elementi base nelle classi del WPF
- Scegliere da quale elemento derivare
API degli elementi base nelle classi del WPF Sia UIElement che ContentElement sono derivati dalla classe DependencyObject, ma con percorsi diversi. La separazione a questo livello riguarda il modo in cui un UIElement oppure un ContentElement sono utilizzati nell'interfaccia utente e qual'è lo scopo a cui servono in un'applicazione. UIElement nella propria gerarchia di classe, ha anche Visual, una classe che espone il supporto grafico a basso livello su cui è basato il WPF. Visual fornisce un infrastruttura di rendering definendo regioni rettangolari dello schermo indipendenti. In pratica, UIElement è predisposto per elementi che supporteranno un object model più ampio, che sono pensati per effettuare il rendering e l'impaginazione in regioni che possono essere descritte come regioni rettangolari dello schermo, nelle quali il modello dei contenuti è deliberatamente più aperto, per permettere diverse combinazioni degli elementi. ContentElement non deriva da Visual; il modello su cui si basa è predisposto affinché il ContentElement sia consumato da qualcos'altro, come un lettore o un visualizzatore che in seguito interpreterà i suoi elementi e produrre il Visual completo che sarà consumato dal WPF. Alcune classi derivate da UIElement sono predisposte quali contenitori di contenuti [scusate n.d.r.], forniscono ospitalità e rendering per una o più classi di tipo ContentElement. (il DocumentViewer è un esempio di classe di questo tipo). ContentElement è usato quale classe base per elementi con un modello ad oggetti in qualche modo più piccolo che si occupano di testo, informazioni o contenuto di documenti che possono essere ospitati all'interno di un UIElement.
UIElement fa da classe base a FrameworkElement, e ContentElement fa da classe base per FrameworkContentElement. La ragione per queste classi di livello superiore è quella di sostenere la separazione fra il livello del nucleo base del WPF ed il livello di infrastruttura (Framework) di WPF. Questa divisione è presente anche nel modo in cui le API sono suddivise fra assembly "PresentationCore" e "PresentationFramework". Il livello Framework del WPF presenta una soluzione più completa per le necessità di base delle applicazioni , inclusa l'implementazione del layout manager per la presentazione. Il livello Core del WPF, fornisce un modo per usare la maggior parte del WPF senza la necessità di assembly addizionali. La distinzione fra questi livelli, ha raramente significato per la maggior parte dei tipici scenari applicativi. In generale dovreste considerare le API del WPF un tutt'uno. La necessità di conoscere la distinzione fra i livelli, sarà opportuna se il progetto della vostra applicazione scegliesse di sostituire in modo sostanziale le funzionalità del WPF a livello di infrastruttura, ad esempio se la vostra soluzione ha già le proprie implementazioni della composizione e disposizione (layout) dell' interfaccia utente.
[Ad esempio se producete controlli e i vostri controlli sono costruiti dalla base derivando quindi da UIElement e ContentElement. n.d.r.]. SScegliere da quale elemento derivare Il metodo più pratico per creare una classe personalizzata che estende il WPF è derivare da una delle classi del WPF in modo tale da ottenere le funzionalità desiderate attraverso la gerarchia di classe. Questa sezione, lista le funzionalità fornite da tre delle più importanti classi elemento per aiutarvi a decidere da quale classe ereditare. Se create una classe che deriva da DependencyObject, ereditate le seguenti funzionalità: - GetValue e SetValue che danno sostegno e supportano il sistema generale delle property.
- L'abilità di utilizzare proprietà dipendenti (Dependency Properties) e proprietà allegate (Attached properties) che sono implementate quali proprietà dipendenti.
[Capito tutto? non vi preoccupate, appena l'ho compreso ve lo spiego in un articolo apposito sulle dependency property n.d.r.]..
Se create una classe che deriva da UIElement, ereditate le seguenti funzionalità, oltre a quelle fornite da DependencyObject:: - Supporto di base per valori animati delle proprietà, per maggiori informazioni vedi Panoramica sull'Animazione
- Supporto di base per gli eventi di input e supporto ai comandi. Per maggiori informazioni, vedi Panoramicasull'Input e Panoramica sui Comandi .
[LLa traduzione comandi è puramente inventata infatti la parola commanding utilizzata nell'originale ha traduzioni poco comprensibili, quali autorevole, imponente e autoritario oppure comandamento. n.d.r.]. - Metodi virtuali di cui è possibile fare l'override per fornire informazioni al sistema di layout.
Se create una classe derivata da FrameworkElement, ereditate le seguenti funzionalità oltre a quelle fornite da UIElement: - Supporto per gli stili e gli storyboards. Vedi Panoramica sugli Stili e Panoramica sugli Storyboards
- Supporto al data binding. Per maggiori informazioni vedi Panoramica sul Databinding .
- Supporto per riferimenti dinamici alle risorse. Per maggiori informazioni, vedi Panoramica sulle Risorse .
- Supporto per l'ereditarietà dei valori delle property, altri flag nei metadati che aiutano ad evidenziare condizioni relative alle proprietà ai servizi dell'infrastruttura (framework) quali databinding, stili, o l'implementazione del layout dell'infrastruttura.
Per maggiori informazioni vedi Framework Property Metadata .. - Il concetto di albero logico. Per maggiori informazioni, vedi Albero degli Elementi .
- Supporto all'implementazione pratica del sistema di layout a livello di infrastruttura del WPF, incluso un override di OnPropertyChanged che può percepire le modifiche alle property che influenzano il layout.
Se create una classe derivata da ContentElement, ereditate le seguenti funzionalità oltre a quelle fornite da DependencyObject: - Supporto alle animazioni. Per maggiori informazioni vedi Panoramica sull'Animazione .
- Supporto di base agli eventi di Input, e supporto ai comandi. Per maggiori informazioni vedi Panoramica sull'Input e Panoramica sui Comandi . [vedi nota su comandi n.d.t.].
Se create una classe che deriva da FrameworkContentElement, avrete le seguenti funzionalità oltre a quelle fornite da ContentElement: - Supporto agli stili e agli storyboards. Per maggiori informazioni vedi Panoramica sugli stili& e Panoramica sull'animazione .
- Supporto per il databinding. Per maggiori informazioni vedi Panoramica sul Data Binding .
- Supporto per il riferimento dinamico alle risorse. Per maggiori informazioni vedi Panoramica sulle Risorse .
- Supporto all'ereditarietà delle property ed altri flag nei metadati che aiutano ad evidenziare condizioni relative alle proprietà ed ai servizi dell'infrastruttura (framework) quali databinding, stili o l'implementazione del layout dell'infrastruttura. Per maggiori informazioni vedi Framework Property Metadata .
- NON ereditate accesso alle modifiche al sistema di layout (quali ArrangeOverride). L'implementazione del sistema di layout è disponibile solo su strong>FrameworkElement. Ad ogni modo, ereditate un override di OnPropertyChanged che può percepire le modifiche alle property che influenzano il layout e riportarle ad ogni contenitore (che ospita il controllo ContentElement).
Se state implementando un controllo, probabilmente deriverete da una classe che è un vero e proprio controllo, una classe base per una famiglia di controlli oppure la classe base Control. Per alcune linee guida ed esempi pratici vedi Panoramica sulla creazione di controlli . I modelli di contenuto sono documentati per una varietà di classi. Il modello di contenuto per una classe è uno dei fattori che dovete considerare quando volete individuare la classe appropriata da cui ereditare. Per maggiori informazioni, vedi Modelli di Contenuti . © 2007 Microsoft Corporation
Trademark information is available at http://www.microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx. Traduzione a cura di Patrizia Cosolo, revisione tecnica a cura di Sabrina Cosolo |