2009-02-28 10 views
1

Fondamentalement, j'ai une liste déroulante et un contrôle utilisateur ajouté dynamiquement. Le contrôle utilisateur charge une vue de grille en fonction du choix effectué dans la liste déroulante. La liste déroulante ne fait pas partie du contrôle utilisateur.ViewState, UserControl et IsPostback

Maintenant, la question est, comment puis-je simuler (isControlPostback = false) chaque fois que l'utilisateur change la sélection dans la liste déroulante? On dirait que ViewState se souvient du contrôle.

intérieur de mon contrôle utilisateur je:

protected bool IsUserControlPostBack 
{ 
    get 
    { 
     return this.ViewState["IsUserControlPostBack"] != null; 
    } 
} 

protected void Page_Load(object sender, EventArgs e) 
{ 
    if (!IsUserControlPostBack) 
    { 
     ViewState.Add("IsUserControlPostBack", true); 
     //load stuff in the grid view and bind it 
    } 
} 

Lorsque l'utilisateur modifie la sélection sur la liste déroulante, j'ai une boîte de confirmation javascript, et les messages de page en arrière. L'événement OnSelectedIndexChanged pour la liste déroulante n'est donc pas déclenché. Je voudrais supprimer pour faire quelque chose comme ça chaque fois que l'index sélectionné change: ViewState.Remove ("IsUserControlPostBack");

+0

Je viens de découvrir que l'événement OnLoad du contrôle est exécuté juste après l'événement OnLoad de la page, et AVANT tout autre événement de la liste déroulante Page. Donc, fondamentalement, je charge le contrôle de l'utilisateur avant que Page ne réagisse aux changements déclenchés par la liste déroulante. Ce comportement est essentiellement le problème. – sarsnake

Répondre

0

Pour tous ceux qui veulent connaître la réponse: Je fini par mettre en œuvre une propriété publique dans le contrôle de l'utilisateur et charger le contrôle à l'intérieur du serveur liste déroulante événement SelectedIndexChanged plutôt que OnInit. Ceci a éliminé le besoin d'utilisation explicite de Viewstate.

0

Ajoutez le contrôle à la page avant OnLoad. Par exemple. OnInit. Entre OnInit et OnLoad, le viewstate est chargé et les événements de publication sont exécutés.

+0

étant déjà ajouté dans OnInit – sarsnake

1

Vous pouvez apporter des modifications au contrôle dans l'événement prerender. Lorsque cet événement est déclenché, toutes les autres actions sont effectuées. Ou vous pouvez faire la propriété publique dans le contrôle de l'utilisateur et lors de la configuration requise pour réagir de façon appropriée.

1

Le ViewState auquel vous accédez dans votre contrôle utilisateur n'est pas le même que celui auquel vous accédez sur la page. Si vous avez besoin de votre page pour communiquer avec votre contrôle utilisateur, je vous suggère d'ajouter une méthode publique sur votre contrôle utilisateur à cette fin.

Si, pour une raison quelconque, vous préférez quelque chose de similaire à votre approche ViewState , vous pouvez essayer Context.Items. Notez que Context.Items n'est pas conservé entre les demandes.

+0

lorsque je charge un contrôle sur une page, je fais quelque chose comme Control control = Load ("controlname.ascx"); Le contrôle aurait-il accès aux méthodes publiques? Le fait est que je ne veux pas que le contrôle se rafraîchisse chaque fois que je le charge - mais seulement quand la liste déroulante change. – sarsnake

+0

Viewstate sur la page est différent de la Viewstate sur le contrôle? C'est une nouvelle pour moi. Avez-vous un lien MSDN qui l'explique? Le but de Viewstate n'est-il pas de tout garder au même endroit? Totalement confus maintenant. – sarsnake

+0

Les données viewstate seront toutes sérialisées en un seul gros morceau, qui est stocké sur la page. Mais les données sont organisées comme des branches dans un arbre, où chaque contrôle a sa propre branche. Néanmoins, ViewState n'est pas pour l'état de partage entre les contrôles. –