L'ultimo attributo che non abbiamo ancora esaminato è x:Class. E' un'informazione utile al generatore di codice che entra in funzione in fase di compilazione, poiché indica il code-behind di questo file, nello stesso identico modo in cui viene fatto per le applicazioni ASP.NET.
L'elemento root che specifichiamo per ogni file XAML è il tipo dal quale la classe autogenerata eredita. Il file Window1.xaml.cs contiene infatti il seguente codice:
public partial class Window1 : Window {
public Window1() {
InitializeComponent();
}
}Prima di tutto notiamo che la classe eredita da Window, dal momento che da essa prendiamo tutte le sue caratteristiche, ma la estendiamo inserendo controlli e codice personalizzato.
Presenta poi la parola chiave partial, il che significa che essa è fusa con la medesima classe definita in un secondo file. Cosa più importante è la chiamata nel costruttore al metodo InitializeComponent, definito nel secondo file di questa classe, che di norma non possiamo vedere e neanche modificare perché autogenerata dal compilatore.
Apriamo la cartella dove risiede il progetto e sfogliamo all'interno di obj\debug. Tra i tanti files, ne è presente uno di nome Window1.g.cs, che depurato di informazioni non importanti contiene questo codice:
public partial class Window1 : System.Windows.Window {
public void InitializeComponent() {
System.Uri resourceLocater = new System.Uri("window1.baml", System.UriKind.RelativeOrAbsolute);
System.Windows.Application.LoadComponent(this, resourceLocater);
}
}La definizione della classe è uguale a quella del codebehind e definisce il metodo InitializeComponent, richiamato nel costruttore. Questo concetto per chi sviluppa per ASP.NET e per Winforms è già conosciuto, ma presenta una differenza importante: non vi è nessun codice per la creazione e la definizione dei controlli specificati nel file XAML.
Ci possiamo aspettare del codice simile a questo:
Grid grid1 = new Grid();
this.Children.Add(grid1);
Button button1 = new Button();
button1.Content = "Hello World!"
grid1.Children.Add(button1);Invece viene richiamato LoadComponent, passando come uri "window1.baml". Questo file è visibile sempre nella stessa directory ed è una versione binaria, compattata ed ottimizzata al caricamento, del nostro file window1.xaml.
Il metodo statico LoadComponent carica questo file ed istanzia a runtime i controlli all'interno della nostra finestra.
In questo modo spostiamo una parte del lavoro dalla compilazione in fase di esecuzione. Questo, se da una parte rallenta un po' il processo di caricamento della nostra applicazione (il codice autogenerato è più performante di un'esecuzione a runtime) dall'altra semplifichiamo uno scenario molto utile: la localizzazione.
Il file window1.baml non è esterno all'applicazione, ma è incluso nelle risorse dell'assembly finale.
Gli assemblies .NET hanno infatti la possibilità di contenere, oltre a codice IL, anche qualsiasi tipo di risorsa binaria: testi, immagini e anche il nostro file .baml.
Inoltre queste DLL portano con sè un'informazione riguardante la localizzazione delle risorse: la culture. Di default è neutrale, ma possiamo generare assemblies satellite che cambiano il loro contenuto in funzione della lingua. Ipoteticamente mioassembly.dll può essere accompagnato da mioassembly.en-US.dll o mioassembly.it-IT.dll che ridefiniscono il file window1.baml con contenuti, nel nostro caso, rispettivamente in inglese e italiano.
Procediamo con il nostro progetto, analizzando ora il file MyApp.xaml. Esso contiene, nello stesso modo di Window1, il codice XAML, ma con root element di nome Application.
Si tratta di una classe che abbiamo già trovato prima e che rappresenta il motore della nostra applicazione, dato che gestisce il message loop proveniente dal mondo unmanged di Win32, la sincronia dei threads e la navigazione delle pagine.
Contenuti dell'articolo
- Pagina 1
- Pagina 2
- Pagina 5
- Introduzione a .NET Micro Framework
- Gestire transazioni miste con NTFS in Windows Server 2008
- Windows Presentation Foundation 3.5: 3D interattivo e le altre novità del framework
- Le novità di Communication e Workflow Foundation e la loro cooperazione nel .NET Framework 3.5
- .NET Framework 3.5 e Visual Studio 2008: cosa c'è di nuovo
- Gestione delle eccezioni in Windows Communication Foundation
- Sviluppare workflow sequenziali con WF
- WPF: dal DataBinding ai Template - Terza parte
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Utilità
Stampa 
Download 
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!