Comment préserver le contrôle de l'etat dans l'onglet éléments dans un TabControl

Je suis un nouveau venu à WPF, de tenter de construire un projet qui suit les recommandations de Josh Smith à l'excellent article décrivant Le Modèle-Vue-Vuemodèle Modèle De Conception.

À l'aide de Josh exemple de code comme base, j'ai créé une application simple qui contient un certain nombre de "espaces de travail", chacun représenté par un onglet dans un TabControl. Dans mon application, un espace de travail est un éditeur de documents qui permet à un document hiérarchique à être manipulé par l'intermédiaire d'un contrôle TreeView.

Bien que j'ai réussi à l'ouverture de plusieurs espaces de travail et la visualisation de leur contenu du document dans le contrôle TreeView, je trouve que le TreeView "oublie" son état lors de la commutation entre les onglets. Par exemple, si le TreeView dans Tab1 est partiellement développé, il sera présenté comme entièrement effondré après le passage à Tab2 et le retour à l'Tab1. Ce comportement semble s'appliquer à tous les aspects du contrôle de l'état de toutes les commandes.

Après quelques essais, j'ai réalisé que je peux conserver un état dans un TabItem explicitement la liaison de chaque contrôle de l'état de la propriété à la propriété sur le sous-jacent ViewModel. Cependant, il semble que beaucoup de travail supplémentaire, quand je veux que tous mes contrôles à se souvenir de leur état lors de la commutation entre les espaces de travail.

Je suppose que je suis absent quelque chose de simple, mais je ne sais pas où trouver la réponse. Des conseils seront très appréciés.

Grâce,
Tim

Mise à jour:

Comme demandé, je vais essayer de publier un peu de code qui illustre ce problème. Cependant, puisque les données qui sous-tend le TreeView est complexe, je vais poster un exemple simplifié qui présente les mêmes symptômes. Voici le code XAML de la fenêtre principale:

<TabControl IsSynchronizedWithCurrentItem="True" ItemsSource="{Binding Path=Docs}">
    <TabControl.ItemTemplate>
        <DataTemplate>
            <ContentPresenter Content="{Binding Path=Name}" />
        </DataTemplate>
    </TabControl.ItemTemplate>

    <TabControl.ContentTemplate>
        <DataTemplate>
            <view:DocumentView />
        </DataTemplate>
    </TabControl.ContentTemplate>
</TabControl>

Ci-dessus XAML correctement se lie à une ObservableCollection de DocumentViewModel, dont chaque membre est présenté par l'intermédiaire d'un DocumentView.

Pour la simplicité de cet exemple, j'ai supprimé le TreeView (mentionné ci-dessus) de la DocumentView et l'a remplacé par un TabControl contenant 3 fixe onglets:

<TabControl>
    <TabItem Header="A" />
    <TabItem Header="B" />
    <TabItem Header="C" />
</TabControl>

Dans ce scénario, il n'y a pas de liaison entre la DocumentView et la DocumentViewModel. Lorsque le code est exécuté, l'intérieur TabControl est incapable de se souvenir de sa sélection lors de l'extérieur TabControl est sous tension.

Cependant, si j'ai choisi de lier l'intérieur TabControl de la propriété SelectedIndex ...

<TabControl SelectedIndex="{Binding Path=SelectedDocumentIndex}">
    <TabItem Header="A" />
    <TabItem Header="B" />
    <TabItem Header="C" />
</TabControl>

... un mannequin bien sur la DocumentViewModel ...

public int SelecteDocumentIndex { get; set; }

... l'intérieure de la languette est en mesure de se souvenir de sa sélection.

Je comprends que je peux résoudre mon problème par l'application de cette technique à chaque propriété visuelle de chaque contrôle, mais j'espère qu'il y a une solution plus élégante.

  • Les contrôles WPF "se souvenir" de leur état par défaut, le fait que les contrôles dans votre onglet objets "oublier" de leur état, est le résultat d'une action explicite de votre part. Montrer le code XAML pour votre onglet éléments, et à la vue du modèle de code pour les liaisons qu'ils contiennent.
  • Je suis d'accord avec Aviad, difficile de dire ce qui ne va pas sans voir votre code. Pour quelques articles sur le contrôle TreeView dans WPF, je suggère de jeter un oeil à la Bea Stollnitz le blog de ... bea.stollnitz.com/blog/index.php?s=treeview
  • Je prends mon commentaire, mais c'est un vrai méchant problème, je l'ai juste essayé de tous les angles, et si l'onglet contrôle à l'aide d'un ItemsSource avec un DataTemplate il semble que l'état visuel des contrôles dans le modèle de données partagé (!!!) parmi l'onglet articles!
  • J'ai eu ce problème avec plus que juste un treeview... si vous n'avez pas de deux façon ViewModel la sauvegarde de l'état de la commande, il la perdra. La raison pour cela est que lorsque vous changer d'onglet, les contrôles ne sont plus partie de l'arborescence visuelle. L'événement Unload est en fait tiré de ces contrôles et ils n'ont plus aucune représentation visuelle jusqu'à ce que vous revenez. C'est une forme de virtualisation qui l'onglet contrôle met en œuvre pour aider à économiser de la mémoire lorsque vous avez beaucoup d'onglets. Très intéressé de savoir si vous avez une solution pour ça... je viens de la création de la Vm.
  • Emi: Vraiment, ce commentaire doit être une réponse.
  • Whitlock - oui, je suis d'accord, Anderson Ime' commentaire semble être aussi proche que j'ai la chance d'arriver à une solution à ce problème. +1.
  • Whitlock merci... j'ai en quelque sorte de se sentir comme il y a encore une sorte de solution de contournement, si. Peut-être que certains WPF maven va venir et nous donner une véritable moyen de préserver l'état visuel.
  • Est-il un moyen de regarder le Visuel de l'Arbre pour voir si il y a un changement? Je suis en train d'appliquer ValidationRules pour toutes les Liaisons sur FrameworkElements dans mon Arborescence Visuelle. Depuis les modifications apportées à l'arbre, je vais avoir des problèmes pour l'application de liaisons pour les éléments.
  • Pouvez vous nous montrez comment vous avez résolu ce problème s'il vous plaît? La réponse ci-dessous je me sens ne pas répondre à la question...
  • IIRC, le WAF de l'échantillon qui existait en janvier 2010 a été très utile pour me guider vers une solution viable, mais a par la suite considérablement évolué, dans la mesure où il essaie de faire beaucoup de choses, et n'est plus très clair sur ce point. J'ai récemment re-visité, pour me rafraîchir la mémoire (n'ayant pas travaillé avec WPF pour près de 3 ans) et a été déçu de découvrir que je ne pouvais pas reproduire ce que j'avais réalisé auparavant. En fin de compte, j'ai eu recours à de la simple création visuelle supplémentaire propriétés de l'état sur le modèle de vue. Désolé que je ne peut pas proposer quelque chose de plus utile.
  • Merci pour votre temps.

InformationsquelleAutor Tim Coulter | 2010-01-17