FrameworkElement.OnVisualParentChanged(DependencyObject) Méthode

  • Référence

Définition

Espace de noms:
System.Windows
Assembly:
PresentationFramework.dll

Appelée en cas de modification du parent de cet élément dans l’arborescence visuelle. Substitue OnVisualParentChanged(DependencyObject).

protected public:
 override void OnVisualParentChanged(System::Windows::DependencyObject ^ oldParent);
protected internal override void OnVisualParentChanged (System.Windows.DependencyObject oldParent);
override this.OnVisualParentChanged : System.Windows.DependencyObject -> unit
Protected Friend Overrides Sub OnVisualParentChanged (oldParent As DependencyObject)

Paramètres

oldParent
DependencyObject

Ancien élément parent. Peut être null pour indiquer que l’élément n’avait pas de parent visuel auparavant.

Remarques

L’arborescence visuelle est potentiellement différente de l’arborescence logique, car elle omet les éléments qui ne s’affichent pas visuellement, tels que les collections, et développe certains éléments en fonction de leur thème et de leur composition de style. Pour plus d’informations, consultez Arborescences dans WPF.

Notes pour les héritiers

L’implémentation par défaut de cette méthode virtuelle interroge le nouveau parent, déclenche différents événements d’initialisation et définit des indicateurs internes sur l’état d’initialisation du, le FrameworkElement cas échéant. Enfin, il appelle les implémentations de base successives comme déclarées par UIElement, qui à son tour appelle sa base dans Visual. Appelez toujours l’implémentation de base pour conserver ce comportement. Sinon, le comportement de l’arborescence d’éléments pour cet élément lorsqu’il est déclaré en tant qu’enfant d’un autre élément peut ne pas être comme prévu.

Quelques classes Windows Presentation Foundation existantes (WPF) remplacent cette méthode, par exemple : OnVisualParentChanged(DependencyObject), OnVisualParentChanged(DependencyObject). Le scénario le plus courant consiste à appliquer que le nouveau parent doit être un type particulier. Cela peut impliquer la levée d’une exception si le nouveau parent a échoué à une certaine manière de test de type. Une version spécialisée de ce scénario existe dans les implémentations pour les éléments de liste et les éléments de menu, qui n’ont aucun sens en dehors d’un visuel parent qui possède une collection appropriée dans laquelle les stocker. Notez que ces cas ne soulèvent pas nécessairement d’exceptions, car il peut y avoir des scénarios de concepteur qui s’appuient sur des éléments de réparent qui sont momentanément sans leurs parents « réguliers ».

Cette méthode est également remplacée dans certains éléments qui sont généralement l’élément racine, comme Window. Un autre cas est celui des éléments qui sont l’élément racine apparent dans le balisage, mais qui génèrent automatiquement une infrastructure plus grande dans une arborescence logique compilée (comme Page). Les Window implémentations et Page scellent délibérément la méthode.

S’applique à

Voir aussi