Totem's Lair: Guida al Vb.Net, Applicazioni Windows Form

B1. Applicazioni Windows Form

Ora spiegherò come funzionano le applicazioni Windows Form, ossia quelle che godono di un'interfaccia grafica a finestre. Prima di iniziare è necessario creare un nuovo progetto: cliccare su File->New Project, quindi su "Windows Application", e successivamente dare un nome al progetto. Ora che è tutto pronto, procediemo.

Descrizione degli strumenti

Pagina iniziale

Questa è l'immagine che si prospetta all'avvio del compilatore con una applicazione windows. Certune volte la pagina iniziale potrebbe essere differente a causa delle impostazioni del compilatore stesso: per farla apparire come illustrato basta premere il pulsante Visualizza Form. Ecco una breve lista con annessa descrizione di ogni componente evidenziato:

Elenco dei controlli (Toolbox) : soffermandocisi sopra con il mouse per pochi secondi, apparirà l'elenco dei controlli disponibili. Un controllo non è altro che una classe, ricca di metodi e proprietà, che trova nel form designer un'interfaccia grafica che lo contraddistingua. In sostanza, un conttrollo è una delle qualsiasi parti che formano una finestra, come una casella di testo, un menù a tendina, una lista, eccetera.
Anteprima del form : qui si possono posizionare i controlli semplicemente trascinandoli dalla toolbox con il mouse. La Windows Form è la finestra per eccellenza ed è essa stessa una classe i cui campi sono i suoi controlli e i cui metodi rappresentano i suoi eventi.
Form Designer : lo spazio in cui viene visualizzata l'anteprima della Windows Form.
Pulsante Esegui : per far correre il programma.
Pulsante Codice : per vedere il sorgente della finestra.
Pulsante Visualizza Form : per visualizzare l'anteprima della form e portarla in primo piano nel designer (in caso ci siano più finestre aperte).
Solution Explorer : serve per visualizzare tutte le risorse, i riferimenti, le finestre e le classi utilizzate nel progetto. Se si sta lavorando con una soluzione, ossia un insieme di più progetti, visualizza tutti i progetti. Facendo doppio click su un elemento lo si può portare in primo piano.
Finestra delle Proprietà : per visualizzare o modificare le proprietà del controllo selezionato. Essendo, come si è visto, "campi intelligenti", le proprietà possono anche lanciare eccezioni mentre le si cambia durante lo sviluppo. Questo è utile per non commettere mai errori di distrazione nell'assegnare valori sbagliati.
Finestra degli errori/warning : dopo ogni modifica al codice sorgente, questa finestra viene aggiornata mostrando tutti gli errori di sintassi e gli warning. Uno warning è un avvertimento: notifica errori logici che potrebbero mandare in crash il programma.

I files del progetto

Il compilatore genera diversi tipi di file, che vengono utilizzati per scopi differenti. Eccone un piccolo elenco:

File *.sln : rappresenta una soluzione, ossia un insieme di più progetti. Se l'applicazione è costituita da un solo progetto, coincide con esso.
File *.vbproj : rappresenta un progetto; alla sua apertura carica automaticamente nel compilatore tutti i riferimenti, le risorse, i codici, le librerie e i file usati nel progetto.
File *.resx : rappresenta un file di risorse; ogni windows form ne ha uno. Questo tipo di file ha il compito di unire in sè tutte le risorse utilizzate. Le risorse sono incluse manualmente del programmatore tramite il comando Add Resource e possono essere file di testo, immagini, filmati, database, eccetera.
File *.vb : rappresenta la più piccola unità di codice. Contiene il sorgente scritto dal programmatore. A differenza del VB6, in cui ogni componente del progetto aveva diversa estensione, nel Vb.Net tutte le parti dell'applicazione, siano esse librerie di classi, controlli utente, finestre o moduli, hanno sempre estensione *.vb. Questa caratteristica è stata introdotta in virtù del fatto che esse sono pur sempre scritte nello stesso linguaggio, il Visual Basic.
File *.Designer.vb : come si è visto precedentemenete, alcune classi possono essere dichiarate Partial, ossia possono contenere il proprio corpo suddiviso in due o più file distinti. Ebbene, questo tipo di file contiene una classe Partial automaticamente generata dal compilatore che serve a produrre (a "disegnare" fisicamente sullo schermo) ogni controllo che il programmatore sposta con il mouse sulla superficie del form designer. Infatti, ogni volta che anche una sola proprietà viene modificata, il compilatore ricrea da zero il file sorgente visuale per aggiornare il form. Ogni finestra avrà quindi due sorgenti: uno scritto da noi (estensione *.vb) e uno scritto dal compilatore (estensione *.Designer.vb).
File *.vshost.exe : questo è un eseguibile creato dal compilatore nella cartella Debug del programma. Il suo compito è di creare un AppDomain (vedi capitolo 44) e associarvi il debugger, ossia il software del compilatore che permette di analizzare e in questo modo correggere il funzionamento del programma durante la sua esecuzione. Nonostante questo processo sia alquanto lungo (la differenza si comincia a notare con programmi di svariate migliaia di righe), dà vantaggi immensi. Permette infatti di intercettare le eccezioni e di segnalarne con esattezza la posizione all'interno del sorgente, di valutare le espressioni o le proprietà a run-time, di ottenere informazioni sul comportamento dell'applicazione e molto altro ancora. Insomma, se non ci fosse, se ne sentirebbe la mancanza.
File *.pdb : file creati dal debugger per contenere le informazioni che vshost.exe intercetta. Sono necessari solo quando si sta eseguendo una versione debug del programma.
File *.xml : contengono informazioni sull'assembly.

Ora che si sono visti i file, è opportuno analizzare anche la funzione delle cartelle. Tutti i progetti creati si trovano di default nella cartella Documenti\Visual Studio 2005\Projects. Ogni programma ha una cartella con il proprio nome che contiene:

1 file *.suo, opzioni utente per la soluzione
1 file *.sln, la soluzione vera e propria
1 cartella con lo stesso nome del programma se l'opzione "Create directory for solution" è attiva. In questo modo si può dividere il file soluzione dagli altri file di progetto. Se l'opzione non è attiva, questa cartella non esiste
1 o più file *.vbproj a seconda di quanti siano i progetti
2 o più file *.vb, sorgenti del programma
1 cartella MyProject, che contiene sotto forma di codice, tutte le informazioni sull'assembly generato (nome, versione, cultura, società, copyright, eccetera), tutti i campi MySettings impostati, tutte le risorse caricate
1 cartella bin, che contiene i file eseguibili
- 1 cartella Debug, che contiene l'eseguibile accompagnato dal file *.vshost.exe e due file di informazioni (*.pdb e *.xml)
- 1 cartella Release, che contiene l'eseguibile completo, che non necessita di nessuna dipendenza (i file di informazioni sono comunque presenti)
1 cartella obj, contenente dati, assembly, informazioni temporanee e oggetti necessari per l'esecuzione in debug e per la successiva costruzione dell'eseguibile finito

N.B.: Se il compilatore utilizzato è SharpDevelop 1.0, non c'è distinzione tra file *.vb e *.Designer.vb: tutto il codice viene scritto nello stesso file.

La struttura per Eventi

Come accennato in precedenza, il Vb.Net è un linguaggio orientato agli oggetti, quindi agli eventi. Un evento rappresenta un qualunque cambiamento dell'oggetto a cui appartiene o una sua interazione con l'utente e viene generato in corrispondenza di questo mutamento. Ad esempio, se si fa click con il mouse su una casella di testo, si cambia il suo stato, che passa da passivo ad attivo, poichè inizia una interazione con l'utente: in questo caso viene generato l'evento Click dell'oggetto in questione. Perciò la struttura del codice di una applicazione windows form è molto differente rispetto a quella fino ad ora usata, e si prospetta in questo modo:

Evento 1
  'Codice da eseguire per l'evento 1
Fine Evento 1

Evento 2
  'Codice da eseguire per l'evento 2
Fine Evento 2

'Eccetera

Gli eventi sono gestiti mediante i delegate. Un oggetto possiede una certa variabile delegate associata all'evento, e quando l'evento viene generato, viene automaticamente invocata la procedura contenuta in quella variabile. Dato che esistono i delegate multicast, è anche possibile associare più procedure a un solo evento o più eventi a una singola procedura. Questa particolare interazione, a livello di sviluppo, è resa della keyword Handles (dall'inglese handle = gestire), la cui funzione consiste nell'associare un pezzo di codice a un evento. Ad esempio:

'Di default le procedure che rappresentano un evento sono sempre private
Private Sub txtName_Click(ByVal sender As Object, _ 
    ByVal e As System.EventArgs) Handles txtName.Click
    'Codice da eseguire quando viene generato l'evento Click sulla
    'casella di testo di nome txtName
End Sub

Attenzione! Per coloro che provengono dal VB6, nel quale il legame tra metodo ed evento era dato solo dal nome della procedura, bisogna far notare che l'unica cosa che viene realmente considerata dal compilatore è la clausola Handles: il nome può cambiare a piacere; resta quindi del tutto arbitrario.

'Nessun errore verrebbe generato con questo codice
Private Sub PincoPallino(ByVal sender As Object, _ 
    ByVal e As System.EventArgs) Handles txtName.Click
    'Codice
End Sub

Ora si deve considerare la signature del metodo. Nel capitolo sui delegate si è visto come il metodo associato a una variabile di tipo delegate debba avere la stessa identica signature del tipo stesso. Dato che gli eventi sono moltissimi e disparati, non tutti presentano la stessa signature. Il primo parametro è lo stesso per tutti: sender rappresenta l'oggetto che ha generato l'evento. Il secondo parametro contiene informazioni riguardo alle modalità in cui l'evento si è scatenato e il suo tipo può variare. Per convenzione, tali parametri devono mantenere lo stesso nome: sender ed e.

The Totem's Lair - Copyright (C) 2009
È vietata la riproduzione sia totale che parziale del sito.