14 messaggi dal 19 marzo 2008
Ho provato lo script ma mi causa il seguente problema:
La pagina chiamante, da cui devo recuperare il valore di alcuni campi, contiene una query SQL con parametri proveninti da un menu contenuto nella masterpage.
Quando richiamo la proprieta PreviousPage è come se ricaricasse la pagina precedente.
Cio provoca un errore in quanto quest'ultima contiene la suddetta query che ha bisogno di alcuni parametri provenienti da un'altra parte, e che perciò non riesce più a trovare.
sì, PreviousPage di fatto fa una istanza della pagina precedente. è per questo che in scenari del genere si usa una tecnica mista: CrossPagePostBack sulla pagina sorgente, ma normale Request.Form su quella di destinazione.
se vuoi semplicemente leggere valori di campi va più che bene.

Daniele Bochicchio | ASPItalia.com | Libri
Chief Operating Officer@iCubed
Microsoft Regional Director & MVP
14 messaggi dal 19 marzo 2008
Daniele Bochicchio ha scritto:
sì, PreviousPage di fatto fa una istanza della pagina precedente. è per questo che in scenari del genere si usa una tecnica mista: CrossPagePostBack sulla pagina sorgente, ma normale Request.Form su quella di destinazione.
se vuoi semplicemente leggere valori di campi va più che bene.


Venendo da ASP Classic, Request.Form è stato il primo tentativo che ho fatto per recuperare i valori della pagina chiamante nella pagina chiamata ma,
a quanto pare, non funzionava se le pagine erano contenute in una masterpage !!

Allora: se non riesco a recuperare il valore dei campi (in questo particolare caso), ne con Request.form, ne con PrevousPage cosa devo pensare...
Che ASP.NET ha delle lacune
Possibile
piercava wrote:
Allora: se non riesco a recuperare il valore dei campi (in questo particolare caso), ne con Request.form, ne con PrevousPage cosa devo pensare...
Che ASP.NET ha delle lacune

è fattibilissimo. il problema è che probabilmente non conosci abbastanza bene ASP.NET.
ti basta sapere lo UniqueID del controllo che ti interessa. una tecnica abbastanza semplice è questa.
metti nella pagina sorgente un campo hidden, così:
<input type="hidden" name="myField" value="<%=TextBox1.UniqueID%>" />
nella pagina ricevente, scrivi
string myValue = Request.Form[Request.Form["myField"];

gli ID dei controlli nelle attuali versioni sono autogenerati e con questa tecnica (ma ce ne sono altre 100) riesci a recuperarlo senza troppi problemi.

Daniele Bochicchio | ASPItalia.com | Libri
Chief Operating Officer@iCubed
Microsoft Regional Director & MVP
14 messaggi dal 19 marzo 2008
Daniele Bochicchio ha scritto:
piercava wrote:
Allora: se non riesco a recuperare il valore dei campi (in questo particolare caso), ne con Request.form, ne con PrevousPage cosa devo pensare...
Che ASP.NET ha delle lacune

è fattibilissimo. il problema è che probabilmente non conosci abbastanza bene ASP.NET.
ti basta sapere lo UniqueID del controllo che ti interessa. una tecnica abbastanza semplice è questa.
metti nella pagina sorgente un campo hidden, così:
<input type="hidden" name="myField" value="<%=TextBox1.UniqueID%>" />
nella pagina ricevente, scrivi
string myValue = Request.Form[Request.Form["myField"];

gli ID dei controlli nelle attuali versioni sono autogenerati e con questa tecnica (ma ce ne sono altre 100) riesci a recuperarlo senza troppi problemi.


L'ID, nella pagina chiamata, lo recupero già in un altro modo.
Però, usando questo ID nella pagina chiamata, non riesco ad ottenere il valore del relativo campo. Request.Form[IDcampo]; mi restituisce null (IDcampo è una variabile che contiene l'ID della textBox contenuta nella pagine d'origine)
Ma questo strano comportamento avviene solo in presenza di una masterpage.
Se la pagina chiamata e quella chiamante non sono contenute nella masterpage funziona tutto regolarmente. Perchè





piercava wrote:
Ma questo strano comportamento avviene solo in presenza di una masterpage. Se la pagina chiamata e quella chiamante *non sono* contenute nella masterpage funziona tutto regolarmente. Perchè

perchè, come ti ho già scritto, gli ID sono generati in base al controllo contenitore. hai provato ad usare il mio snippet di codice? ad occhio e croce no, perchè altrimenti avresti risolto.

Daniele Bochicchio | ASPItalia.com | Libri
Chief Operating Officer@iCubed
Microsoft Regional Director & MVP
14 messaggi dal 19 marzo 2008
Daniele Bochicchio ha scritto:
piercava wrote:
Ma questo strano comportamento avviene solo in presenza di una masterpage. Se la pagina chiamata e quella chiamante *non sono* contenute nella masterpage funziona tutto regolarmente. Perchè

perchè, come ti ho già scritto, gli ID sono generati in base al controllo contenitore. hai provato ad usare il mio snippet di codice? ad occhio e croce no, perchè altrimenti avresti risolto.


Ho appena provato e non funziona !!
Boh
Premetto che i controlli li creo run time nella pagina asp.cs
Ecco lo script che riproduce esattamente le tue istruzioni:

Nella pagina chiamante
TextBox quantita = new TextBox();
HiddenField quantitaHid = new HiddenField();
quantita.ID = Convert.ToString(r);
quantitaHid.ID = Convert.ToString(r)+"h";
quantitaHid.Value = quantita.UniqueID;
(r è un indice di riga che uso per dare un'ID ai campi della tabella creata anch'essa run time)

Nella pagina chiamata:
string IDquantita = Request.QueryString["quantita"];
string quantita = Request.Form[Request.Form[IDquantita+"h"]];

quantita continua a essere uguale a Null.
(Ho verificato che la stringa URL passa esattmente l'ID del campo che mi interessa.)
piercava wrote:
Ho appena provato e non funziona !!

è ovvio che non vada: tu crei a runtime i controlli, che avranno quindi l'ID auto generato. per questo motivo anche l'hiddenfiled che vorresti usare come "ponte" subisce la stessa fine.
in sintesi: se crei a runtime i controlli, creano uno literal con all'interno il tuo ID. più o meno una roba tipo:

Literal c = new Literal();
c.Text = string.Format("<input id=\"myfieldID\" ... value=\"{0}\" />", myField.ClientID);
container.Controls.Add(c);

Daniele Bochicchio | ASPItalia.com | Libri
Chief Operating Officer@iCubed
Microsoft Regional Director & MVP

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.