Il sogno è iniziato quando mi sono ricordato del l'overload nel metodo LoadControl:

public Control LoadControl (

Type t,

Object[] parameters

)

Il Metodo è esposto da tutte le pagine che lo ereditano da TemplateControl.

Che figo! mi sono detto, posso istanziare un UserControl passando dei parametri al costruttore!
in parte è vero in parte no.

nella mia paginetta facevo in questo modo:

Type type = BuildManager.GetCompiledType("~/MyUserControl.ascx");

il metodo restituisce il tipo compilato del percorso specificato e successivamente:

MyPlaceHolder.Controls.Add(LoadControl(type, new object[] { "pippo" }));

Risultato? Una bella eccezione , perche? Semplice quanto dimenticarselo.

Tramite un BuildProvider che a sua volta si serve di un parser, il nostro del file ascx da vita a una classe, che eredita dalla classe specificata dalla proprietà Inherits della direttiva @Page.

Alla fine avremo una classe myusercontrol_ascx che eredita da MyUserControl, la prima ha il classico costruttore senza parametro, la seconda ha i costruttori che ho definito.

Il problema si può aggirare facendo così

Type type = BuildManager.GetCompiledType("~/MyUserControl.ascx").BaseType
MyPlaceHolder.Controls.Add(LoadControl(type, new object[] { "pippo" }));

in modo da passare a metodo il Type MyUserControl con i suoi costruttori.

Risultato? Una pagina vuota senza i controlli dichiarati nell'UserControl o una bella eccezione se tentate di accedere a qualsiasi proprietà dei questi.

Alla fine nulla di arcano tutto normale, la Classe MyUserControl non ha la logica per istanziare i controlli, logica che invece si trova in myusercontrol_ascx (che eredita da MyUserControl)

Insomma da una parte ho i costruttori dall'altra la logica d'inizializzazione, ma allora a cosa serve l'overload di LoadControl?