Discussion :

[JolyLoic]

Bonjour,

J'ai écrit dans le fichier generic.xaml le code suivant qui marche, pour ajouter un menu déroulant à mon custom control TabControl2 (ouais, je sais, le nom... Mais j'expérimente simplement), dérivé de TabControl :

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
    <ContextMenu x:Key="TabContextMenu">
        <MenuItem Header="Context menu"/>
    </ContextMenu>
 
    <Style TargetType="{x:Type local:TabControl2}" BasedOn="{StaticResource {x:Type TabControl}}">
        <Setter Property="TabPanel.ContextMenu"  Value="{StaticResource TabContextMenu}" />
    </Style>

Et ça marche. Quel est le problème alors ? C'est qu'avant d'en arriver là, j'avais fait l'essai suivant :

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
    <Style TargetType="{x:Type local:TabControl2}" BasedOn="{StaticResource {x:Type TabControl}}">
        <Setter Property="TabPanel.ContextMenu">
            <Setter.Value>
                <ContextMenu>
                    <MenuItem Header="Context menu bis"/>
                </ContextMenu>
            </Setter.Value>
        </Setter>
    </Style>

A ce que j'ai cru comprendre au XAML, ce code devrait être équivalent au premier (mais mieux, car évitant de polluer le dictionnaire avec une information privée). Or s'il compile, il plante à l'exécution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Impossible d'ajouter un contenu de type 'System.Windows.Controls.ContextMenu' à un objet de type 'System.Object'.

Quelqu'un pourrait-il m'expliquer la différence profonde entre ces deux bouts de code ?

Merci !

[MetalGeek]

Salut,
dans le XAML si tu ajoutes un élément comme enfant d'un autre, il faut que la classe behind correspondante ait marqué la propriété comme étant un contenu (attribut "ContentProperty", enfin si je me souviens bien).
Comme ce n'est pas le cas avec la propriété Value de l'objet Setter, le compilateur considère que c'est faux car tu ne peux pas attacher un frameworkelement comme enfant visuel logique de "Value" du "Setter" (en fait, toi, tu veux le valoriser au niveau de la cible du Setter). Tu rencontreras le même phénomène si tu essaies de faire un truc du genre qui suit sur un style pour ContentControl :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
<Setter Property="Content">
    <Setter.Value>
......
</Setter>

Idem pour les propriétés Child des ViewBox et autres, etc...

Je ne sais pas si j'ai été clair, si quelqu'un de plus pédagogue passe dans le coin...

[JolyLoic]

Je vais tenter de reformuler, voir si j'ai bien compris : Le faire que ce qu'on set par l'intermédiaire d'un setter accepte un sous arbre XAML est totalement indépendant du fait que la propriété value du setter accepte ou pas un sous arbre. Et en l'occurrence, elle ne l'accepte pas.

C'est bien ça ?

[MetalGeek]

je viens de me relire le lendemain, effectivement je suis pas des plus clairs mdr...

De manière plus "pratique" :

Si tu écris ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
                            <FrameworkElement>
                                <FrameworkElement.ContextMenu>
                                    <ContextMenu>
                                        ...
                                    </ContextMenu>
                                </FrameworkElement.ContextMenu>
                            </FrameworkElement>

Le compilateur va capter que tu affectes un objet ContextMenu que tu déclares comme menu contextuel de l'élément, parce que ça se passe dans l'arborescence de l'élément (au niveau de la déclaration, attention, les ContextMenu ne font pas partie du même VisualTree et ne sont pas "enfants" au sens hierarchique de l'élément auquel tu les "attaches").

Par contre, dans ton exemple (valoriser la propriété ContextMenu par le biais d'un Setter), le compilateur semble en quelque sorte "isoler" le contexte de l'élément, et pour lui la propriété ContextMenu étant de type Object, il ne voit pas à quoi relier le truc ; en fait c'est comme s'il traduisais ton xaml comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
<object>
    <ContextMenu>
        ...
    </ContextMenu>
 </object>

Du coup, comme le code behind de "object" ne prévoit pas la gestion du contenu direct en xaml, il te sort cette superbe Exception...

Une chose est sûre, les exceptions et le débuggage en général en WPF c'est assez déstabilisant, surtout au début (si tu t'amuses à filer les StackTrace de ce genre d'erreurs, tu hallucines devant le nombre de méthodes parcourues pour un simple "Click" par exemple...)