Partager via

Vue d’ensemble des propriétés de dépendance

  • Article

Cette rubrique explique le système de propriétés de dépendance disponible lorsque vous écrivez une application Windows Runtime à l’aide de C++, C# ou Visual Basic, ainsi que des définitions XAML pour l’interface utilisateur.

Qu’est-ce qu’une propriété de dépendance ?

Une propriété de dépendance est un type spécialisé de propriété. Plus précisément, il s’agit d’une propriété où la valeur de la propriété est suivie et influencée par un système de propriétés dédié qui fait partie de Windows Runtime.

Pour prendre en charge une propriété de dépendance, l’objet qui définit la propriété doit être un DependencyObject (en d’autres termes, une classe qui a la classe de base DependencyObject quelque part dans son héritage). La plupart des types que vous utilisez pour vos définitions d’interface utilisateur pour une application UWP avec XAML seront une sous-classe DependencyObject et prendront en charge les propriétés de dépendance. Toutefois, tout type provenant d’un espace de noms Windows Runtime qui n’a pas de « XAML » dans son nom ne prend pas en charge les propriétés de dépendance ; les propriétés de ces types sont des propriétés ordinaires qui n’auront pas le comportement de dépendance du système de propriétés.

L’objectif des propriétés de dépendance est de fournir un moyen systémique de calculer la valeur d’une propriété en fonction d’autres entrées (autres propriétés, événements et états qui se produisent dans votre application pendant son exécution). Ces autres entrées peuvent inclure :

  • Entrée externe telle que la préférence utilisateur
  • Mécanismes de détermination des propriétés juste-à-temps tels que la liaison de données, les animations et les storyboards
  • Modèles de création de modèles à plusieurs utilisations, tels que les ressources et les styles
  • Valeurs connues par le biais de relations parent-enfant avec d’autres éléments de l’arborescence d’objets

Une propriété de dépendance représente ou prend en charge une fonctionnalité spécifique du modèle de programmation pour définir une application Windows Runtime avec XAML pour l’interface utilisateur et C#, les extensions de composant Microsoft Visual Basic ou Visual C++ (C++/CX) pour le code. Voici quelques fonctionnalités :

  • Liaison de données
  • Styles
  • Animations dans une table de montage séquentiel
  • Comportement « PropertyChanged » ; une propriété de dépendance peut être implémentée pour fournir des rappels qui peuvent propager des modifications à d’autres propriétés de dépendance
  • Utilisation d’une valeur par défaut provenant des métadonnées de propriété
  • Utilitaire de système de propriétés général, tel que ClearValue et recherche de métadonnées

Propriétés de dépendance et propriétés Windows Runtime

Les propriétés de dépendance étendent la fonctionnalité de base des propriétés Windows Runtime en fournissant un magasin de propriétés interne global qui sauvegarde toutes les propriétés de dépendance dans une application au moment de l’exécution. Il s’agit d’une alternative au modèle standard de sauvegarde d’une propriété avec un champ privé privé dans la classe de définition de propriété. Vous pouvez considérer ce magasin de propriétés interne comme étant un ensemble d’identificateurs de propriété et de valeurs qui existent pour n’importe quel objet particulier (tant qu’il s’agit d’un DependencyObject). Au lieu d’être identifiée par nom, chaque propriété du magasin est identifiée par une instance DependencyProperty. Toutefois, le système de propriétés masque principalement ce détail d’implémentation : vous pouvez généralement accéder aux propriétés de dépendance à l’aide d’un nom simple (le nom de propriété programmatique dans le langage de code que vous utilisez ou un nom d’attribut lorsque vous écrivez du code XAML).

Le type de base qui fournit les sous-épinglages du système de propriétés de dépendance est DependencyObject. DependencyObject définit des méthodes qui peuvent accéder à la propriété de dépendance et les instances d’une classe dérivée DependencyObject prennent en charge en interne le concept de magasin de propriétés que nous avons mentionné précédemment.

Voici une somme de la terminologie que nous utilisons dans la documentation lors de la discussion des propriétés de dépendance :

Terme Description
Propriété de dépendance Propriété qui existe sur un identificateur DependencyProperty (voir ci-dessous). En règle générale, cet identificateur est disponible en tant que membre statique de la classe dérivée DependencyObject de définition.
Identificateur de propriété de dépendance Valeur constante pour identifier la propriété, elle est généralement publique et en lecture seule.
Wrapper de propriété Implémentations get et set pouvant être appelées pour une propriété Windows Runtime. Ou, la projection propre au langage de la définition d’origine. Une implémentation get property wrapper appelle GetValue, en passant l’identificateur de propriété de dépendance approprié.

Le wrapper de propriétés n’est pas seulement pratique pour les appelants, il expose également la propriété de dépendance à n’importe quel processus, outil ou projection qui utilise des définitions Windows Runtime pour les propriétés.

L’exemple suivant définit une propriété de dépendance personnalisée telle que définie pour C#, et montre la relation de l’identificateur de propriété de dépendance à l’wrapper de propriété.

public static readonly DependencyProperty LabelProperty = DependencyProperty.Register(
  "Label",
  typeof(string),
  typeof(ImageWithLabelControl),
  new PropertyMetadata(null)
);


public string Label
{
    get { return (string)GetValue(LabelProperty); }
    set { SetValue(LabelProperty, value); }
}

Remarque

L’exemple précédent n’est pas destiné à l’exemple complet pour créer une propriété de dépendance personnalisée. Il est destiné à afficher les concepts de propriété de dépendance pour toute personne qui préfère apprendre des concepts par le biais du code. Pour obtenir une explication plus complète de cet exemple, consultez les propriétés de dépendance personnalisées.

Priorité de la valeur d’une propriété de dépendance

Lorsque vous obtenez la valeur d’une propriété de dépendance, vous obtenez une valeur qui a été déterminée pour cette propriété via l’une des entrées qui participent au système de propriétés Windows Runtime. La priorité des valeurs de propriété de dépendance existe afin que le système de propriétés Windows Runtime puisse calculer les valeurs de manière prévisible, et il est important que vous soyez familiarisé avec l’ordre de priorité de base également. Sinon, vous pouvez vous trouver dans une situation où vous essayez de définir une propriété à un niveau de précédence, mais quelque chose d’autre (le système, les appelants tiers, certains de votre propre code) le définit à un autre niveau, et vous serez frustré d’essayer de déterminer quelle valeur de propriété est utilisée et où cette valeur provient.

Par exemple, les styles et les modèles sont destinés à être un point de départ partagé pour établir des valeurs de propriété et donc des apparences d’un contrôle. Toutefois, sur une instance de contrôle particulière, vous pouvez modifier sa valeur par rapport à la valeur modèle commune, par exemple en donnant à ce contrôle une couleur d’arrière-plan différente ou une chaîne de texte différente en tant que contenu. Le système de propriétés Windows Runtime considère les valeurs locales à priorité supérieure aux valeurs fournies par les styles et les modèles. Cela permet au scénario d’avoir des valeurs spécifiques à l’application remplacer les modèles afin que les contrôles soient utiles pour votre propre utilisation dans l’interface utilisateur de l’application.

Liste de priorité des propriétés de dépendance

Voici l’ordre définitif que le système de propriétés utilise lors de l’affectation de la valeur d’exécution pour une propriété de dépendance. La priorité la plus élevée est répertoriée en premier. Vous trouverez des explications plus détaillées juste après cette liste.

  1. Valeurs animées : animations actives, animations d’état visuel ou animations avec un comportement HoldEnd. Pour avoir un effet pratique, une animation appliquée à une propriété doit avoir la priorité sur la valeur de base (non animée), même si cette valeur a été définie localement.
  2. Valeur locale : une valeur locale peut être définie par le biais de la commodité du wrapper de propriétés, qui équivaut également à définir en tant qu’attribut ou élément de propriété en XAML, ou par un appel à la méthode SetValue à l’aide d’une propriété d’une instance spécifique. Si vous définissez une valeur locale à l’aide d’une liaison ou d’une ressource statique, ces derniers agissent dans la priorité comme si une valeur locale a été définie, et les liaisons ou références de ressources sont effacées si une nouvelle valeur locale est définie.
  3. Propriétés basées sur des modèles : un élément a ces éléments s’il a été créé dans le cadre d’un modèle (à partir d’un ControlTemplate ou d’un DataTemplate).
  4. Setters de style : valeurs d’un setter dans des styles à partir de ressources de page ou d’application.
  5. Valeur par défaut : une propriété de dépendance peut avoir une valeur par défaut dans le cadre de ses métadonnées.

Propriétés de modèle

Les propriétés de modèle comme élément de priorité ne s’appliquent à aucune propriété d’un élément que vous déclarez directement dans le balisage de page XAML. Le concept de propriété basé sur un modèle existe uniquement pour les objets créés lorsque Windows Runtime applique un modèle XAML à un élément d’interface utilisateur et définit ainsi ses visuels.

Toutes les propriétés définies à partir d’un modèle de contrôle ont des valeurs d’un certain type. Ces valeurs sont presque comme un ensemble étendu de valeurs par défaut pour le contrôle et sont souvent associées aux valeurs que vous pouvez réinitialiser ultérieurement en définissant les valeurs de propriété directement. Par conséquent, les valeurs de jeu de modèles doivent être distinguées d’une valeur locale vraie, afin que toute nouvelle valeur locale puisse la remplacer.

Remarque

Dans certains cas, le modèle peut remplacer même les valeurs locales si le modèle n’a pas pu exposer les références d’extension de balisage {TemplateBinding} pour les propriétés qui doivent avoir été définies sur des instances. Cela est généralement effectué uniquement si la propriété n’est pas vraiment destinée à être définie sur des instances, par exemple si elle est uniquement pertinente pour les visuels et le comportement du modèle et non pour la fonction ou la logique d’exécution prévue du contrôle qui utilise le modèle.

Liaisons et précédence

Les opérations de liaison ont la priorité appropriée pour toute étendue utilisée. Par exemple, un {Binding} appliqué à une valeur locale agit comme valeur locale et une extension de balisage {TemplateBinding} pour un setter de propriétés s’applique comme un setter de style. Étant donné que les liaisons doivent attendre jusqu’à ce que l’exécution obtienne des valeurs à partir de sources de données, le processus de détermination de la priorité de la valeur de propriété pour toute propriété s’étend également dans le temps d’exécution.

Non seulement les liaisons fonctionnent-elles avec la même priorité qu’une valeur locale, elles sont vraiment une valeur locale, où la liaison est l’espace réservé pour une valeur différée. Si vous avez une liaison en place pour une valeur de propriété et que vous définissez une valeur locale sur celle-ci au moment de l’exécution, qui remplace entièrement la liaison. De même, si vous appelez SetBinding pour définir une liaison qui entre uniquement en existence au moment de l’exécution, vous remplacez toute valeur locale que vous avez peut-être appliquée en XAML ou par du code précédemment exécuté.

Animations de tableau séquentiel et valeur de base

Les animations de tableau séquentiel agissent sur un concept de valeur de base. La valeur de base est la valeur déterminée par le système de propriétés à l’aide de sa priorité, mais omettant cette dernière étape de recherche d’animations. Par exemple, une valeur de base peut provenir du modèle d’un contrôle, ou elle peut provenir de la définition d’une valeur locale sur une instance d’un contrôle. Dans les deux cas, l’application d’une animation remplace cette valeur de base et applique la valeur animée tant que votre animation continue à s’exécuter.

Pour une propriété animée, la valeur de base peut toujours avoir un effet sur le comportement de l’animation, si cette animation ne spécifie pas explicitement From et To, ou si l’animation rétablit la propriété à sa valeur de base une fois terminée. Dans ces cas, une fois qu’une animation n’est plus en cours d’exécution, le reste de la priorité est utilisé à nouveau.

Toutefois, une animation qui spécifie une Valeur à avec un comportement HoldEnd peut remplacer une valeur locale jusqu’à ce que l’animation soit supprimée, même lorsqu’elle semble être arrêtée visuellement. Conceptuellement, il s’agit d’une animation qui s’exécute pour toujours même s’il n’y a pas d’animation visuelle dans l’interface utilisateur.

Plusieurs animations peuvent être appliquées à une propriété unique. Chacune de ces animations a peut-être été définie pour remplacer les valeurs de base provenant de points différents dans la priorité des valeurs. Toutefois, ces animations s’exécutent toutes simultanément au moment de l’exécution, ce qui signifie souvent qu’elles doivent combiner leurs valeurs, car chaque animation a une influence égale sur la valeur. Cela dépend de la manière exacte dont les animations sont définies et du type de la valeur qui est animée.

Pour plus d’informations, consultez animations storyboarded.

Valeurs par défaut

L’établissement de la valeur par défaut d’une propriété de dépendance avec une valeur PropertyMetadata est expliqué plus en détail dans la rubrique propriétés de dépendance personnalisée.

Les propriétés de dépendance ont toujours des valeurs par défaut, même si ces valeurs par défaut n’ont pas été explicitement définies dans les métadonnées de cette propriété. À moins qu’elles n’aient été modifiées par les métadonnées, les valeurs par défaut des propriétés de dépendance Windows Runtime sont généralement l’une des suivantes :

  • Une propriété qui utilise un objet d’exécution ou le type objet de base (un type référence) a une valeur par défaut null. Par exemple, DataContext est null jusqu’à ce qu’il soit délibérément défini ou hérité.
  • Une propriété qui utilise une valeur de base telle que des nombres ou une valeur booléenne (un type valeur) utilise une valeur par défaut attendue pour cette valeur. Par exemple, 0 pour les entiers et les nombres à virgule flottante, false pour un booléen.
  • Une propriété qui utilise une structure Windows Runtime a une valeur par défaut obtenue en appelant le constructeur par défaut implicite de cette structure. Ce constructeur utilise les valeurs par défaut pour chacun des champs de valeur de base de la structure. Par exemple, une valeur par défaut pour une valeur point est initialisée avec ses valeurs X et Y comme 0.
  • Une propriété qui utilise une énumération a une valeur par défaut du premier membre défini dans cette énumération. Vérifiez la référence des énumérations spécifiques pour voir quelle est la valeur par défaut.
  • Une propriété qui utilise une chaîne (System.String pour .NET, Platform ::String pour C++/CX) a une valeur par défaut d’une chaîne vide («  »).
  • Les propriétés de collection ne sont généralement pas implémentées en tant que propriétés de dépendance, pour des raisons décrites plus loin dans cette rubrique. Toutefois, si vous implémentez une propriété de collection personnalisée et que vous souhaitez qu’elle soit une propriété de dépendance, veillez à éviter un singleton involontaire, comme décrit près de la fin des propriétés de dépendance personnalisées.

Fonctionnalité de propriété fournie par une propriété de dépendance

Liaison de données

Une propriété de dépendance peut avoir sa valeur définie via l’application d’une liaison de données. La liaison de données utilise la syntaxe d’extension de balisage {Binding} en XAML, l’extension de balisage {x :Bind} ou la classe Binding dans le code. Pour une propriété de trafic de données, la détermination de la valeur de propriété finale est différée jusqu’au moment de l’exécution. À ce stade, la valeur est obtenue à partir d’une source de données. Le rôle que joue le système de propriétés de dépendance ici est d’activer un comportement d’espace réservé pour les opérations telles que le chargement xaml lorsque la valeur n’est pas encore connue, puis en fournissant la valeur au moment de l’exécution en interagissant avec le moteur de liaison de données Windows Runtime.

L’exemple suivant définit la valeur Text d’un élément TextBlock à l’aide d’une liaison en XAML. La liaison utilise un contexte de données hérité et une source de données d’objet. (Aucun de ces éléments n’est affiché dans l’exemple raccourci ; pour un exemple plus complet qui montre le contexte et la source, voir Liaison de données en profondeur.)

<Canvas>
  <TextBlock Text="{Binding Team.TeamName}"/>
</Canvas>

Vous pouvez également établir des liaisons à l’aide du code plutôt que du code XAML. Consultez SetBinding.

Remarque

Les liaisons comme celles-ci sont traitées comme une valeur locale à des fins de priorité de valeur de propriété de dépendance. Si vous définissez une autre valeur locale pour une propriété qui contenait initialement une valeur de liaison, vous remplacerez entièrement la liaison, pas seulement la valeur d’exécution de la liaison. {x :Bind} Les liaisons sont implémentées à l’aide du code généré qui définit une valeur locale pour la propriété. Si vous définissez une valeur locale pour une propriété qui utilise {x :Bind}, cette valeur sera remplacée la prochaine fois que la liaison est évaluée, par exemple lorsqu’elle observe une modification de propriété sur son objet source.

Sources de liaison, cibles de liaison, rôle de FrameworkElement

Pour être la source d’une liaison, une propriété n’a pas besoin d’être une propriété de dépendance ; vous pouvez généralement utiliser n’importe quelle propriété comme source de liaison, bien que cela dépend de votre langage de programmation et chacun possède certains cas de périphérie. Toutefois, pour être la cible d’une extension de balisage {Binding} ou binding, cette propriété doit être une propriété de dépendance. {x :Bind} n’a pas cette exigence, car il utilise du code généré pour appliquer ses valeurs de liaison.

Si vous créez une liaison dans le code, notez que l’API SetBinding est définie uniquement pour FrameworkElement. Toutefois, vous pouvez créer une définition de liaison à l’aide de BindingOperations à la place, et donc référencer n’importe quelle propriété DependencyObject.

Pour le code ou XAML, n’oubliez pas que DataContext est une propriété FrameworkElement. En utilisant une forme d’héritage de propriété parent-enfant (généralement établie dans le balisage XAML), le système de liaison peut résoudre un DataContext qui existe sur un élément parent. Cet héritage peut évaluer même si l’objet enfant (qui a la propriété cible) n’est pas FrameworkElement et ne contient donc pas sa propre valeur DataContext . Toutefois, l’élément parent hérité doit être un FrameworkElement pour définir et contenir dataContext. Vous devez également définir la liaison de sorte qu’elle puisse fonctionner avec une valeur Null pour DataContext.

Le câblage de la liaison n’est pas la seule chose nécessaire pour la plupart des scénarios de liaison de données. Pour qu’une liaison unidirectionnelle ou bidirectionnelle soit effective, la propriété source doit prendre en charge les notifications de modification qui se propagent au système de liaison et, par conséquent, la cible. Pour les sources de liaison personnalisées, cela signifie que la propriété doit être une propriété de dépendance, ou que l’objet doit prendre en charge INotifyPropertyChanged. Les collections doivent prendre en charge INotifyCollectionChanged. Certaines classes prennent en charge ces interfaces dans leurs implémentations afin qu’elles soient utiles en tant que classes de base pour les scénarios de liaison de données ; Un exemple de telle classe est ObservableCollection<T>. Pour plus d’informations sur la liaison de données et la façon dont la liaison de données est liée au système de propriétés, consultez La liaison de données en profondeur.

Remarque

Les types répertoriés ici prennent en charge les sources de données Microsoft .NET. Les sources de données C++/CX utilisent différentes interfaces pour la notification de modification ou le comportement observable, consultez la liaison de données en profondeur.

Styles et modèles

Les styles et les modèles sont deux des scénarios de définition des propriétés en tant que propriétés de dépendance. Les styles sont utiles pour définir les propriétés qui définissent l’interface utilisateur de l’application. Les styles sont définis en tant que ressources en XAML, soit en tant qu’entrée dans une collection Resources , soit dans des fichiers XAML distincts, tels que des dictionnaires de ressources de thème. Les styles interagissent avec le système de propriétés, car ils contiennent des setters pour les propriétés. La propriété la plus importante ici est la propriété Control.Template d’un contrôle : elle définit la plupart de l’apparence visuelle et de l’état visuel d’un contrôle. Pour plus d’informations sur les styles et un exemple XAML qui définit un style et utilise des setters, consultez Contrôles de style.

Les valeurs provenant de styles ou de modèles sont des valeurs différées, similaires aux liaisons. Cela permet aux utilisateurs de contrôler de nouveau les contrôles ou de redéfinir les styles. Et c’est pourquoi les setters de propriétés dans les styles ne peuvent agir que sur les propriétés de dépendance, et non sur les propriétés ordinaires.

Animations dans une table de montage séquentiel

Vous pouvez animer la valeur d’une propriété de dépendance à l’aide d’une animation storyboarded. Les animations de tableau séquentiel dans Windows Runtime ne sont pas simplement des décorations visuelles. Il est plus utile de considérer les animations comme étant une technique d’ordinateur d’état qui peut définir les valeurs des propriétés individuelles ou de tous les éléments visuels et propriétés d’un contrôle, et modifier ces valeurs au fil du temps.

Pour être animée, la propriété cible de l’animation doit être une propriété de dépendance. En outre, pour être animé, le type de valeur de la propriété cible doit être pris en charge par l’un des types d’animation dérivés de chronologie existants. Les valeurs de couleur, de double et de point peuvent être animées à l’aide de techniques d’interpolation ou d’images clés. La plupart des autres valeurs peuvent être animées à l’aide d’images clés d’objet discrètes.

Lorsqu’une animation est appliquée et en cours d’exécution, la valeur animée fonctionne à une priorité plus élevée que n’importe quelle valeur (telle qu’une valeur locale) dont la propriété a autrement. Les animations ont également un comportement HoldEnd facultatif qui peut entraîner l’application d’animations aux valeurs de propriété même si l’animation semble être arrêtée.

Le principe de l’ordinateur d’état est incorporé par l’utilisation d’animations storyboarded dans le cadre du modèle d’état VisualStateManager pour les contrôles. Pour plus d’informations sur les animations storyboarded, consultez animations storyboarded. Pour plus d’informations sur VisualStateManager et la définition d’états visuels pour les contrôles, consultez les animations storyboarded pour les états visuels ou les modèles de contrôle.

Comportement modifié par la propriété

Le comportement modifié par propriété est l’origine de la partie « dépendance » de la terminologie de propriété de dépendance. Le maintien de valeurs valides pour une propriété quand une autre propriété peut influencer la valeur de la première propriété est un problème de développement difficile dans de nombreux frameworks. Dans le système de propriétés Windows Runtime, chaque propriété de dépendance peut spécifier un rappel qui est appelé chaque fois que sa valeur de propriété change. Ce rappel peut être utilisé pour notifier ou modifier les valeurs de propriété associées de manière généralement synchrone. De nombreuses propriétés de dépendance existantes ont un comportement modifié par les propriétés. Vous pouvez également ajouter un comportement de rappel similaire aux propriétés de dépendance personnalisées et implémenter vos propres rappels modifiés par propriété. Consultez les propriétés de dépendance personnalisées pour obtenir un exemple.

Windows 10 introduit la méthode RegisterPropertyChangedCallback. Cela permet au code d’application de s’inscrire aux notifications de modification lorsque la propriété de dépendance spécifiée est modifiée sur une instance de DependencyObject.

Valeur par défaut et ClearValue

Une propriété de dépendance peut avoir une valeur par défaut définie dans le cadre de ses métadonnées de propriété. Pour une propriété de dépendance, sa valeur par défaut n’est pas pertinente une fois que la propriété a été définie la première fois. La valeur par défaut peut s’appliquer à nouveau au moment de l’exécution chaque fois que d’autres déterminants dans la précédence des valeurs disparaissent. (La priorité de la valeur de propriété de dépendance est décrite dans la section suivante.) Par exemple, vous pouvez supprimer délibérément une valeur de style ou une animation qui s’applique à une propriété, mais vous souhaitez que la valeur soit une valeur par défaut raisonnable une fois que vous l’avez fait. La valeur par défaut de la propriété de dépendance peut fournir cette valeur, sans avoir à définir spécifiquement la valeur de chaque propriété en tant qu’étape supplémentaire.

Vous pouvez définir délibérément une propriété sur la valeur par défaut même après l’avoir déjà définie avec une valeur locale. Pour réinitialiser une valeur à nouveau comme valeur par défaut, et pour permettre aux autres participants de précédence qui peuvent remplacer la valeur par défaut, mais pas une valeur locale, appelez la méthode ClearValue (référencez la propriété pour effacer en tant que paramètre de méthode). Vous ne souhaitez pas toujours que la propriété utilise littéralement la valeur par défaut, mais l’effacement de la valeur locale et la restauration de la valeur par défaut peuvent permettre à un autre élément de priorité que vous souhaitez agir maintenant, comme l’utilisation de la valeur provenant d’un setter de style dans un modèle de contrôle.

DependencyObject et threading

Toutes les instances DependencyObject doivent être créées sur le thread d’interface utilisateur associé à la fenêtre active affichée par une application Windows Runtime. Bien que chaque DependencyObject soit créé sur le thread d’interface utilisateur principal, les objets sont accessibles à l’aide d’une référence de répartiteur à partir d’autres threads, en accédant à la propriété Dispatcher. Vous pouvez ensuite appeler des méthodes telles que RunAsync sur l’objet CoreDispatcher et exécuter votre code dans les règles des restrictions de thread sur le thread d’interface utilisateur.

Les aspects threading de DependencyObject sont pertinents, car cela signifie généralement que seul le code qui s’exécute sur le thread d’interface utilisateur peut changer ou même lire la valeur d’une propriété de dépendance. Les problèmes de threading peuvent généralement être évités dans le code d’interface utilisateur classique qui utilise correctement les modèles asynchrones et les threads de travail en arrière-plan. En règle générale, vous rencontrez uniquement des problèmes de thread liés à DependencyObject si vous définissez vos propres types DependencyObject et que vous tentez de les utiliser pour des sources de données ou d’autres scénarios où un DependencyObject n’est pas nécessairement approprié.

Matériel conceptuel