Variables et postback

Bonjour,

je rencontre un problème lors d'un postback,
j'ai crée des variables hors du Page_Load sans les initialiser, comme ceci :

Code:

---

1 2 3 4 5 6 7

public partial class maClasse : System.Web.UI.Page { string _maVariableTexte; DateTime _maVariableDate; ... }

---

Je ne peux donc pas utiliser de if(!IsPostBack), ni utiliser de variables de session (j'ai plusieurs objets que je veux garder comme tels).

Le souci évidemment, c'est que lorsqu'un contrôle appelle le PostBack, mes variables retrouvent leur valeur à null.

Quelqu'un possède une solution ou une idée ?
Merci !

Citation:

---

Le souci évidemment, c'est que lorsqu'un contrôle appelle le PostBack, mes variables retrouvent leur valeur à null.

---

normal puisqu'il y a eu postback, donc réinitialisation des membres de ta classe.
si tu ne veux pas stocker tes variables dans une session , utilise le viewstate

Il n'y a pas de solution. Tous les champs des pages n'ont pas de persistance entre les différents postback.

Un contournement est d'utiliser les différents mécanismes de gestion d'état de l'ASPNET : ViewState, Session, ... afin de conserver l'objet.

Une autre possibilité est de recharger les données dont tu as besoin dans chaque pageload indépendamment d'un postback.

Merci pour ces réponses si rapides,
j'ai entendu parler du ViewState, sans trouver d'exemple concret pour cet exemple simple de variables...

quand tu initialisera tes variables

Code:

---

1 2	_maVariableTexte="un certain texte";

---

faire ceci :

Code:

---

1 2 3 4 5

if (ViewState["montexte"] == null) ViewState["montexte"]="un certain texte";   _maVariableTexte=ViewState["montexte"];

---

pour une date ou un objet de quelconque type tu fais un cast sur ta variable viewstate

Code:

---

1 2 3 4 5

if (ViewState["monobjet"] == null) ViewState["monobjet"]=new UnCertainObjet(....);   _maVariableObjet=(UnCertainObjet) ViewState["monobjet"];

---

je te laisse le soin de gérer les exceptions de type cast ou nullreference

sachant que le viewstate alourdi ta page. donc surveille ce point car proposer des pages de 300ko aux utilisateurs, c'est pas forcément la solution non plus

Citation:

---

Envoyé par Louis-Guillaume Morand

sachant que le viewstate alourdi ta page. donc surveille ce point car proposer des pages de 300ko aux utilisateurs, c'est pas forcément la solution non plus

---

effectivement puisque le viewstate "est" un champs type hidden sur la page
asp.net offre plusieurs mécanismes pour gérer les états, chacun avec des défauts et des qualité, il faudra choisir ce qui te conviendra

Merci beaucoup, j'ai mis un peu de temps à l'adapter mais en tous cas ça fonctionne, et l'application n'a pas l'air plus lente pour autant !

Citation:

---

Envoyé par Ashura95

Merci beaucoup, j'ai mis un peu de temps à l'adapter mais en tous cas ça fonctionne, et l'application n'a pas l'air plus lente pour autant !

---

c'est pas l'appli qui est lente, c'est le transfert de données. toi tu testes en local donc c'est normal que tu ne vois pas de différence. Mais en réseau et spécialement si ton application est disponible alors SI, forcément, ca aura une incidence.

faut toujours se dire que la personne en face a p-e une connexion bas débit.

si la quantité des données à stocker est relativement petite, la dite incidence ne sera pas visible.
de toute façon dans toutes les méthodes qu'on pourra utiliser il y aura une incidence quelque part