Leggendo questo articolo di K. Scott Allen, ho scoperto alcune
cose interessanti sull'AutoEventWireup in ASP.NET 2.0 che riporto qui.
AutoEventWireup e' abilitato di default in C# (=true) mentre e'
disabilitato in VB (=false).
In VB quindi in dobbiamo usare la keyword Handles
per connettere l'evento al "handler"
che lo gestisce:
Protected Sub Page_Load(ByVal sender As Object, _
ByVal e As System.EventArgs) _
Handles Me.Load
mentre in C# basta seguire la convenzione dei nomi e chiamare il metodo
Page_EventoDaGestire
protected void Page_Load(object sender, EventArgs e)
Se settiamo AutoEventWireup=true su VB possiamo fare a
meno di specificare la clausola Handles
e seguire la convenzione
come specificato sopra, mentre se disabilitiamo AutoEventWireup in C# dobbiamo
fare il "wire up" dell'evento manualmente:
Load += new EventHandler(Page_Load);
Ok, fino a qui tutto bene, tutte cose gia' viste molte
volte.
In ASP.NET 2.0 quando AutoEventWireup e' abilitato, il runtime controlla
l'esistenza di un metodo collegato ad un evento (cioe' che segue la
convenzione Page_EventoDaGestire), creando un
delegate con il nome del metodo usando CreateDelegate della classe Delegate.
Per la classe Page ci sono 14 eventi che il runtime controllera'
durente l'esecuzione (14 chiamate a CreateDelegate), ma la cosa strana e che il runtime
permette di avere anche "handlers" senza parametri del tipo:
protected void Page_Load()
Quindi fara' altre 14 chiamate a CreateDelegate per
controllare se esistono metodi senza parametri, per un totale di 28
chiamate!
powered by IMHO 1.3