Partager via

Vue d’ensemble des panneaux personnalisés XAML

Un panneau est un objet qui fournit un comportement de disposition pour les éléments enfants qu’il contient, lorsque le système de disposition XAML (Extensible Application Markup Language) s’exécute et que l’interface utilisateur de votre application est affichée.

APIs importantes: Panneau, ArrangeOverride, MeasureOverride

Vous pouvez définir des panneaux personnalisés pour la disposition XAML en dérivant une classe personnalisée à partir de la classe Panel. Vous fournissez un comportement pour votre panneau en remplaçant le MeasureOverride et ArrangeOverride, en fournissant une logique qui mesure et dispose les éléments enfants.

La classe de base du panneau

Pour définir une classe personnalisée de panneau, vous pouvez hériter directement depuis la classe Panel, ou hériter depuis l'une des classes de panneau pratiques qui ne sont pas scellées, telles que Grid ou StackPanel. Il est plus facile de dériver de panneau, car il peut être difficile de contourner la logique de disposition existante d’un panneau qui a déjà un comportement de disposition. En outre, un panneau avec comportement peut avoir des propriétés existantes qui ne sont pas pertinentes pour les fonctionnalités de disposition de votre panneau.

À partir de panneau, votre panneau personnalisé hérite de ces API :

  • Propriété Children.
  • Les propriétés Background, ChildrenTransitions, IsItemsHost ainsi que les identificateurs de propriété de dépendance. Aucune de ces propriétés n’est virtuelle, donc vous ne les remplacez généralement pas. Vous n’avez généralement pas besoin de ces propriétés pour les scénarios de panneau personnalisés, pas même pour la lecture de valeurs.
  • Les méthodes de remplacement de disposition MeasureOverride et ArrangeOverride. Celles-ci ont été définies à l’origine par FrameworkElement. La classe de base Panel ne les remplace pas, mais les panneaux pratiques comme Grid ont des implémentations de remplacement implémentées en tant que code natif et exécutées par le système. Fournir de nouvelles implémentations (ou additionnelles) pour ArrangeOverride et MeasureOverride constitue la majeure partie de l'effort nécessaire pour définir un panneau personnalisé.
  • Toutes les autres API de FrameworkElement, UIElement et DependencyObject, comme Height, Visibility, etc. Vous référencez parfois les valeurs de ces propriétés dans vos surcharges de mise en page, mais elles ne sont pas virtuelles, vous ne les remplacez donc généralement pas ni ne les substituez.

L'objectif ici est de décrire les concepts de mise en page XAML, afin que vous puissiez envisager toutes les possibilités de comment un panneau personnalisé peut et doit se comporter dans la mise en page. Si vous préférez vous lancer directement et voir un exemple d’implémentation de panneau personnalisé, consultez BoxPanel, un exemple de panneau personnalisé.

Propriété Children

La propriété Children est pertinente pour un panneau personnalisé, car toutes les classes dérivées de Panel utilisent la propriété Children comme emplacement pour stocker leurs éléments enfants dans une collection. Children est désigné comme la propriété de contenu XAML pour la classe Panel, et toutes les classes dérivées de Panel peuvent hériter du comportement de la propriété de contenu XAML. Si une propriété est désignée comme propriété de contenu XAML, cela signifie que le balisage XAML peut omettre un élément de propriété lors de la spécification de cette propriété dans le balisage et que les valeurs sont définies en tant qu’enfants de balisage immédiat (le « contenu »). Par exemple, si vous dérivez une classe nommée CustomPanel de Panneau qui ne définit aucun nouveau comportement, vous pouvez toujours utiliser ce balisage :

<local:CustomPanel>
  <Button Name="button1"/>
  <Button Name="button2"/>
</local:CustomPanel>

Lorsqu’un analyseur XAML lit ce balisage, Children sont connus comme la propriété de contenu XAML pour tous les types dérivés Panel, de sorte que l’analyseur ajoutera les deux éléments Button à la valeur UIElementCollection de la propriété Children . La propriété de contenu XAML facilite une relation parent-enfant rationalisée dans le balisage XAML pour une définition d’interface utilisateur. Pour plus d’informations sur les propriétés de contenu XAML et sur la façon dont les propriétés de collection sont remplies lorsque XAML est analysé, consultez le guide de syntaxe XAML .

Le type de collection qui maintient la valeur de la propriété Children est la classe UIElementCollection. UIElementCollection est une collection fortement typée qui utilise UIElement comme type d’élément imposé. UIElement est un type de base hérité par des centaines de types d’éléments d’interface utilisateur pratiques, de sorte que l'imposition du type ici est délibérément souple. Mais cela fait en sorte que vous ne puissiez pas avoir de Pinceau comme enfant direct d’un panneau, ce qui signifie généralement que seuls les éléments destinés à être visibles dans l'interface utilisateur et à participer à la mise en page sont trouvés comme éléments enfants dans un Panneau.

En règle générale, un panneau personnalisé accepte n’importe quel élément enfant UIElement défini par XAML, simplement en utilisant les caractéristiques de la propriété Children as-is. En tant que scénario avancé, vous pouvez prendre en charge la vérification de type supplémentaire des éléments enfants lorsque vous effectuez une itération sur la collection dans vos remplacements de disposition.

Outre la boucle à travers la collection Children dans les remplacements, la logique de votre panneau peut aussi être influencée par Children.Count. Vous pouvez avoir une logique qui alloue de l’espace au moins en partie en fonction du nombre d’éléments, plutôt que des tailles souhaitées et des autres caractéristiques d’éléments individuels.

Substitution des méthodes de disposition

Le modèle de base pour les méthodes de remplacement de disposition (MeasureOverride et ArrangeOverride) consiste à itérer à travers tous les éléments enfants et à appeler la méthode de disposition spécifique de chaque élément enfant. Le premier cycle de disposition commence lorsque le système de disposition XAML définit le visuel de la fenêtre racine. Étant donné que chaque parent appelle la mise en page de ses enfants, cela propage un appel aux méthodes de mise en page pour chaque élément d'interface utilisateur censé faire partie d'un agencement. Dans la disposition XAML, il existe deux étapes : la mesure, puis l’organiser.

Vous n’obtenez aucun comportement de méthode de disposition intégrée pour MeasureOverride et ArrangeOverride à partir de la classe Panel de base. Les éléments de Enfants ne s’affichent pas automatiquement dans l’arborescence des visuels XAML. Il vous incombe de faire connaître les éléments au processus de disposition en invoquant les méthodes de disposition sur chacun des éléments que vous trouvez dans Children lors d'une phase de disposition dans vos implémentations de MeasureOverride et ArrangeOverride.

Il n’existe aucune raison d’appeler des implémentations de base dans les remplacements de disposition, sauf si vous avez votre propre héritage. Les méthodes natives pour le comportement de disposition (si elles existent) s’exécutent dans tous les cas, et ne pas appeler l'implémentation de base avec les surcharges n’empêche pas le comportement natif de se produire.

Pendant la passe de mesure, votre logique de disposition interroge chaque élément enfant pour sa taille souhaitée en appelant la méthode Measure sur cet élément enfant. L’appel de la méthode Measure établit la valeur de la propriété DesiredSize. La valeur de retour MeasureOverride est la taille souhaitée pour le panneau lui-même.

Pendant la passe d’organisation, les positions et les tailles des éléments enfants sont déterminées dans l’espace x-y et la composition de disposition est préparée pour le rendu. Votre code doit appeler Arrange sur chaque élément enfant de Children afin que le système de présentation détecte que l’élément appartient à la présentation. L'appel Arrange est un précurseur à la composition et au rendu ; il informe le système de disposition de l'emplacement de cet élément lorsque la composition est soumise pour le rendu.

De nombreuses propriétés et valeurs contribuent à la façon dont la logique de disposition fonctionnera au moment de l’exécution. Un moyen de réfléchir au processus de disposition est que les éléments sans enfants (généralement l’élément le plus profondément imbriqué dans l’interface utilisateur) sont ceux qui peuvent finaliser les mesures en premier. Ils n'ont aucune dépendance à des éléments enfants qui influencent leur taille souhaitée. Ils peuvent avoir leurs propres tailles souhaitées, et ce sont des propositions de taille jusqu’à ce que la disposition ait réellement lieu. Ensuite, la passe de mesure continue à parcourir l’arborescence visuelle jusqu’à ce que l’élément racine ait ses mesures et que toutes les mesures puissent être finalisées.

La disposition candidate doit s’adapter à la fenêtre d’application actuelle, sinon des parties de l’interface utilisateur seront tronquées. Les panneaux sont souvent l’endroit où la logique de découpage est déterminée. La logique du panneau peut déterminer la taille disponible à partir du MeasureOverride implémentation, et peut avoir à pousser les restrictions de taille sur les enfants et à diviser l’espace entre les enfants afin que tout s’adapte le mieux possible. Le résultat de la disposition est idéalement un élément qui utilise différentes propriétés de toutes les parties de la disposition, mais qui s’inscrit toujours dans la fenêtre de l’application. Cela nécessite une bonne implémentation pour la logique de disposition des panneaux, ainsi qu’une conception d’interface utilisateur judicieuse dans le cadre de tout code d’application qui génère une interface utilisateur à l’aide de ce panneau. Aucune conception de panneau ne va bien paraître si la conception globale de l’interface utilisateur inclut plus d’éléments enfants qu’il n’en peut contenir dans l’application.

Une grande partie de ce qui rend le système de disposition fonctionnel est que tout élément basé sur FrameworkElement a déjà un comportement inhérent quand il agit en tant qu'enfant dans un conteneur. Par exemple, il existe plusieurs API de FrameworkElement qui déterminent le comportement de la mise en page ou sont nécessaires pour que la mise en page fonctionne. Voici quelques-uns des éléments suivants :

MeasureOverride

La méthode MeasureOverride a une valeur de retour utilisée par le système de disposition comme DesiredSize de départ pour le panneau lui-même, lorsque la méthode Measure est appelée sur le panneau par son parent dans la disposition. Les choix logiques au sein de la méthode sont tout aussi importants que ce qu’il retourne, et la logique influence souvent la valeur retournée.

Toutes les implémentations MeasureOverride doivent parcourir childrenet appeler la méthode Measure sur chaque élément enfant. L’appel de la méthode Measure établit la valeur de la propriété DesiredSize. Cela peut indiquer combien d’espace le panneau lui-même a besoin, ainsi que la façon dont cet espace est divisé entre les éléments ou dimensionné pour un élément enfant particulier.

Voici un squelette très basique d’une méthode MeasureOverride :

protected override Size MeasureOverride(Size availableSize)
{
    Size returnSize; //TODO might return availableSize, might do something else
     
    //loop through each Child, call Measure on each
    foreach (UIElement child in Children)
    {
        child.Measure(new Size()); // TODO determine how much space the panel allots for this child, that's what you pass to Measure
        Size childDesiredSize = child.DesiredSize; //TODO determine how the returned Size is influenced by each child's DesiredSize
        //TODO, logic if passed-in Size and net DesiredSize are different, does that matter?
    }
    return returnSize;
}

Les éléments ont souvent une taille naturelle au moment où ils sont prêts pour la disposition. Une fois la mesure passée, le DesiredSize pourrait indiquer la taille naturelle, si la taille disponible que vous avez fournie pour le Mesure était plus petite. Si la taille naturelle est supérieure à la taille disponible que vous avez passée pour Measure, la taille souhaitée est limitée à la taille disponible. C’est ainsi que l'implémentation interne de Mesurese comporte, et vos ajustements de disposition doivent prendre en compte ce comportement.

Certains éléments n’ont pas de taille naturelle, car ils ont valeurs de automatique pour Height et Width. Ces éléments utilisent l'ensemble de la taille disponible , car c’est ce que représente une valeur Auto : ajuster l'élément à sa taille maximale disponible, que le parent immédiat de la mise en page communique en appelant Measure avec availableSize. Dans la pratique, il existe toujours une mesure à laquelle une interface utilisateur est dimensionnée (même s'il s'agit de la fenêtre de niveau supérieur). Finalement, la passe de mesure résout toutes les valeurs de Auto en contraintes parentales et tous les éléments de valeur Auto obtiennent des mesures réelles (que vous pouvez obtenir en vérifiant ActualWidth et ActualHeight, après l'achèvement de la mise en page).

Il est légal de passer une taille à Mesure qui a au moins une dimension infinie, pour indiquer que le panneau peut tenter de s’ajuster aux mesures de son contenu. Chaque élément enfant en cours de mesure définit sa valeur DesiredSize en utilisant sa taille naturelle. Ensuite, pendant la passe d’organisation, le panneau s’organise généralement à l’aide de cette taille.

Les éléments de texte tels que TextBlock ont une largeur et une hauteur réelles calculées, ActualWidth et ActualHeight, en fonction de leur chaîne de texte et de leurs propriétés de texte, même si aucune valeur de hauteur Height ou de largeur Width n'est définie, et ces dimensions doivent être respectées par votre logique de panneau. L'affichage de texte tronqué est une expérience utilisateur particulièrement mauvaise.

Même si votre implémentation n’utilise pas les mesures de taille souhaitées, il est préférable d’appeler la méthode Measure sur chaque élément fils, car il existe des comportements internes et natifs déclenchés lorsque Measure est appelé. Pour qu’un élément participe à la disposition, chaque élément enfant doit avoir Measure appelé sur lui pendant la passe de mesure, et la méthode Arrange appelée sur lui lors de la passe de disposition. L’appel de ces méthodes définit des indicateurs internes sur l’objet et remplit des valeurs (telles que la propriété DesiredSize) dont la logique de disposition du système a besoin lorsqu’elle génère l’arborescence visuelle et affiche l’interface utilisateur.

La valeur de retour MeasureOverride est basée sur la logique du panneau qui interprète la DesiredSize ou d’autres considérations de taille pour chacun des éléments enfants de Children lorsque Measure est appelée sur eux. Que faire avec les valeurs de DesiredSize des enfants et comment la valeur de retour de MeasureOverride doit les utiliser dépend de l'interprétation de votre propre logique. Généralement, vous ne totalisez pas les valeurs sans les modifier, car le paramètre d'entrée de MeasureOverride est souvent une taille disponible fixe proposée par le parent du panneau. Si vous dépassez cette taille, le panneau lui-même risque d'être rogné. Vous comparez généralement la taille totale des enfants à la taille disponible du panneau et apportez des ajustements si nécessaire.

Conseils et orientation

  • Dans l’idéal, un panneau personnalisé doit convenir pour être le premier véritable visuel dans une composition d’interface utilisateur, peut-être à un niveau immédiatement sous Page, UserControl ou un autre élément qui est la racine de la Page XAML. Dans les implémentations de MeasureOverride, ne retournez pas systématiquement la taille d'entrée Size sans examiner les valeurs. Si le retour Size a une valeur Infinity en son sein, cela peut générer des exceptions dans la logique de disposition d’exécution. Une valeur Infinity peut provenir de la fenêtre principale de l’application, qui est défilante et n’a donc pas de hauteur maximale. D’autres contenus défilants peuvent avoir le même comportement.
  • Une autre erreur courante dans implémentations de MeasureOverride consiste à retourner une nouvelle taille par défaut (les valeurs de hauteur et de largeur sont 0). Vous pouvez commencer par cette valeur, et il peut même s'agir de la valeur correcte si votre comité détermine qu'aucun des enfants ne doit être rendu. Toutefois, une taille par défaut entraîne la taille de votre panneau qui n’est pas correctement dimensionnée par son hôte. Il ne demande pas d’espace dans l’interface utilisateur et n’obtient donc aucun espace et ne s’affiche pas. Dans le cas contraire, tout le code de votre panneau peut fonctionner correctement, mais vous ne verrez toujours pas votre panneau ou son contenu s’il est composé avec une hauteur nulle, une largeur nulle.
  • Dans les remplacements, évitez la tentation de convertir des éléments enfants en FrameworkElement et utilisez des propriétés calculées en fonction de la mise en page, en particulier ActualWidth et ActualHeight. Pour les scénarios les plus courants, vous pouvez baser la logique sur la valeur de l'élément enfant DesiredSize, et vous n’aurez pas besoin des propriétés associées à la hauteur Height ou à la largeur Width d’un élément enfant. Dans les cas spécialisés, où vous connaissez le type d’élément et que vous disposez d’informations supplémentaires, par exemple la taille naturelle d’un fichier image, vous pouvez utiliser les informations spécialisées de votre élément, car il ne s’agit pas d’une valeur qui est activement modifiée par les systèmes de disposition. L’inclusion de propriétés calculées par la disposition dans le cadre de la logique de disposition augmente considérablement le risque de définir une boucle de disposition involontaire. Ces boucles entraînent une condition dans laquelle une disposition valide ne peut pas être créée et le système peut lever un LayoutCycleException si la boucle n’est pas récupérable.
  • Les panneaux divisent généralement leur espace disponible entre plusieurs éléments enfants, même si la manière dont cet espace est divisé peut varier. Par exemple, Grid implémente la logique de disposition qui utilise ses valeurs de RowDefinition et de ColumnDefinition pour diviser l'espace en cellules du Grid, prenant en charge à la fois le dimensionnement en étoile et les valeurs en pixels. S'il s'agit de valeurs de pixels, la taille disponible pour chaque enfant est déjà connue, c'est donc cette taille qui est passée comme taille d'entrée pour une Mesure.
  • Les panneaux eux-mêmes peuvent créer un espace réservé pour la marge entre les éléments. Si vous procédez ainsi, veillez à exposer les mesures en tant que propriété distincte de Margin ou toute propriété Padding.
  • Les éléments peuvent avoir des valeurs pour leurs propriétés ActualWidth et ActualHeight en fonction d’un passage de disposition précédent. Si les valeurs changent, le code de l’interface utilisateur de l’application peut placer des gestionnaires pour LayoutUpdated sur les éléments s’il existe une logique spéciale à exécuter, mais la logique du panneau n’a généralement pas besoin de vérifier les modifications avec la gestion des événements. Le système de mise en page détermine déjà quand réexécuter la mise en page, car une propriété pertinente pour celle-ci a changé de valeur, et les MeasureOverride ou ArrangeOverride sont appelées automatiquement dans les circonstances appropriées.

OrganiserRemplacement

La méthode ArrangeOverride a une valeur de retour Size utilisée par le système de disposition lorsque le panneau lui-même est rendu, lorsque la méthode Arrange est appelée sur le panneau par son parent dans la mise en page. Il est courant que l’entrée finalSize et ArrangeOverride retourné Size soient identiques. Si ce n'est pas le cas, cela signifie que le panneau tente de prendre une taille différente de celle que les autres éléments de la mise en page jugent disponible. La taille finale était basée sur l’exécution précédente de la passe de mesure de disposition par le biais de votre code de panneau. C’est pourquoi le retour d’une autre taille n’est pas classique : cela signifie que vous ignorez délibérément la logique de mesure.

Ne retournez pas de Size avec un composant Infinity. Essayer d'utiliser une taille telle que déclenche une exception de la mise en page interne.

Toutes les implémentations de ArrangeOverride doivent parcourir Children, et appeler la méthode Arrange sur chaque élément enfant. Comme Mesure, Arrange n’a pas de valeur de retour. Contrairement à Measure, aucune propriété calculée n’est définie en conséquence (toutefois, l’élément en question déclenche généralement un événement LayoutUpdated).

Voici un squelette très basique d’une méthode ArrangeOverride :

protected override Size ArrangeOverride(Size finalSize)
{
    //loop through each Child, call Arrange on each
    foreach (UIElement child in Children)
    {
        Point anchorPoint = new Point(); //TODO more logic for topleft corner placement in your panel
       // for this child, and based on finalSize or other internal state of your panel
        child.Arrange(new Rect(anchorPoint, child.DesiredSize)); //OR, set a different Size 
    }
    return finalSize; //OR, return a different Size, but that's rare
}

L'étape de mise en page peut se produire sans être précédée par une étape de mesure. Toutefois, cela se produit uniquement lorsque le système de disposition n’a déterminé qu’aucune propriété n’a changé qui aurait affecté les mesures précédentes. Par exemple, si un alignement change, il n’est pas nécessaire de mesurer à nouveau cet élément particulier, car son DesiredSize ne change pas lorsque son choix d’alignement change. En revanche, si ActualHeight change sur un élément quelconque d’une disposition, une nouvelle passe de mesure est nécessaire. Le système de disposition détecte automatiquement les changements réels des mesures et effectue à nouveau la passe de mesure, puis exécute une autre passe d'arrangement.

L’entrée de Arrange prend une valeur Rect. La façon la plus courante de construire cette Rect consiste à utiliser le constructeur qui a une entrée Point et une entrée Size. Le point est l'endroit où le coin supérieur gauche de la boîte englobante de l’élément doit être placé. La Size est les dimensions utilisées pour afficher cet élément particulier. Vous utilisez souvent la valeur DesiredSize pour cet élément comme valeur Size, car l'établissement du DesiredSize pour tous les éléments impliqués dans la disposition était l'objectif de la passe de mesure de la disposition. (Le passage de mesure détermine le dimensionnement global des éléments de manière itérative, afin que le système de disposition puisse optimiser leur placement lors de la passe d'agencement.)

Ce qui varie généralement entre les implémentations de ArrangeOverride est la logique par laquelle le panneau détermine le composant Point de la manière dont il organise chaque enfant. Un panneau de positionnement absolu tel que Canvas utilise les informations de positionnement explicites qu’il obtient à partir de chaque élément via les valeurs de Canvas.Left et de Canvas.Top. Un panneau de division d’espace tel que Grid aurait des opérations mathématiques qui divisent l’espace disponible en cellules et chaque cellule a une valeur x-y pour laquelle son contenu doit être placé et organisé. Un panneau adaptatif tel que StackPanel peut s'étendre pour s'adapter au contenu dans sa dimension d'orientation.

Il existe encore des influences de positionnement supplémentaires sur les éléments de disposition, au-delà de ce que vous contrôlez directement et passez à Organiser. Celles-ci proviennent de l’implémentation native interne de Arrange commune à tous les FrameworkElement types dérivés et augmentée par d'autres types comme les éléments de texte. Par exemple, les éléments peuvent avoir des marges et un alignement, et certains peuvent avoir un espacement intérieur. Ces propriétés interagissent souvent. Pour plus d’informations, consultez Alignement, marge et remplissage.

Panneaux et contrôles

Évitez de placer des fonctionnalités dans un panneau personnalisé qui doit être généré en tant que contrôle personnalisé. Le rôle d’un panneau est de présenter le contenu de tous les éléments enfants qu'il contient, selon une disposition qui se fait automatiquement. Le panneau peut ajouter des décorations au contenu (similaire à la façon dont un Bordure ajoute la bordure autour de l’élément qu’il présente) ou effectuer d’autres ajustements liés à la disposition comme le remplissage. Mais c’est à peu près aussi loin que vous devriez aller dans l'extension de la sortie de l’arborescence visuelle au-delà de la présentation des rapports et de l’utilisation des informations provenant des enfants.

S’il existe une interaction accessible à l’utilisateur, vous devez écrire un contrôle personnalisé, et non un panneau. Par exemple, un panneau ne doit pas ajouter de fenêtres d’affichage défilantes au contenu qu’il présente, même si l’objectif est d’empêcher la troncation, car les barres de défilement, les curseurs, etc., sont des éléments de contrôle interactifs. (Le contenu peut avoir des barres de défilement après tout, mais vous devez laisser cela jusqu’à la logique de l’enfant. Ne la forcez pas en ajoutant le défilement en tant qu’opération de disposition.) Vous pouvez créer un contrôle et également écrire un panneau personnalisé qui joue un rôle important dans l’arborescence visuelle de ce contrôle, quand il s’agit de présenter du contenu dans ce contrôle. Mais le contrôle et le panneau doivent être des objets de code distincts.

Une raison pour laquelle la distinction entre contrôle et panneau est importante est en raison de Microsoft UI Automation et de l'accessibilité. Les panneaux fournissent un comportement de disposition visuelle, et non un comportement logique. La façon dont un élément d’interface utilisateur apparaît visuellement n’est pas un aspect de l’interface utilisateur qui est généralement important pour les scénarios d’accessibilité. L’accessibilité consiste à exposer les parties d’une application qui sont logiquement importantes pour comprendre une interface utilisateur. Lorsque l’interaction est nécessaire, les contrôles doivent exposer les possibilités d’interaction à l’infrastructure UI Automation. Pour plus d'informations, consultez partenaires d'automatisation personnalisés.

Autre API de mise en page

Il existe d’autres API qui font partie du système de disposition, mais qui ne sont pas déclarées par Panneau. Vous pouvez les utiliser dans une implémentation de panneau ou dans un contrôle personnalisé qui utilise des panneaux.

  • UpdateLayout, InvalidateMeasureet InvalidateArrange sont des méthodes qui lancent une passe de disposition. InvalidateArrange peut ne pas déclencher une passe de mesure, mais les deux autres le font. N'appelez jamais ces méthodes depuis une surcharge de méthode de disposition, car elles sont presque sûres de provoquer une boucle de disposition. Le code de contrôle n’a généralement pas besoin de les appeler non plus. La plupart des aspects de la disposition sont déclenchés automatiquement en détectant les modifications apportées aux propriétés de disposition définies par l’infrastructure, telles que largeur, etc.
  • LayoutUpdated est un événement qui se déclenche lorsque certains aspects de la disposition de l’élément ont changé. Ce n’est pas spécifique aux panneaux ; l’événement est défini par FrameworkElement.
  • SizeChanged est un événement qui se déclenche uniquement une fois les passes de disposition finalisées, et indique que ActualHeight ou ActualWidth ont changé en conséquence. Il s’agit d’un autre événement FrameworkElement. Il existe des cas où LayoutUpdated se déclenche, mais SizeChanged ne se déclenche pas. Par exemple, le contenu interne peut être réorganisé, mais la taille de l’élément n’a pas changé.

Référence

Concepts relatifs aux SMS

  • Last updated on