Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Toujours des différences de comportement entre WPF et Silverlight

Silverlight 2 (beta 1) ressemble maintenant beaucoup à ce que l'on a pu apprendre avec WPF. Et en voyant la version alpha, on sait que ce n'était pas gagné d'avance. Beaucoup de concepts de WPF sont maintenant communs à Silverlight. Par exemple le styling et templating, le layout (d'ailleurs extensible exactement de la même façon qu'avec WPF), le binding, de nombreux contrôles communs à WPF, et bien d'autres choses.

Par contre, lorsque l'on regarde un peu plus dans les détails, on commence a remarquer beaucoup de différences. Par exemple, je me trompe peut être mais les Triggers pour les ControlTemplates ne sont pas présents dans Silverlight 2 beta 1. Un autre détail m'a frappé.

Silverlight 2 dispose maintenant du système de Dependency Properties qui comme pour WPF, est au coeur du databinding (je vous renvoie à cet article pour plus de détails sur les Dependency Properties). J'ai noté différence dans le comportement entre ces deux APIs.

Supposons que vous définissiez une dependency property comme ceci, avec son wrappeur CLR :

public static readonly DependencyProperty MassProperty = DependencyProperty.Register("Mass", typeof(float), typeof(Planet));

public float Mass
{
    get { return (float
)GetValue(MassProperty); }
    set { SetValue(MassProperty, value
); }
}

Lorsque vous définissez la propriété Mass depuis le XAML, la dependency property nommée Mass est directement définie, sans passer par le setter de la propriété CLR Mass. En Silverlight par contre, c'est le setter de la propriété CLR qui est appelée. Dans le cas ci-dessus, le résultat est bien sûr le même, mais si on décide de faire des choses supplémentaires dans le setter (ou même le getter), celles-ci seront appelées dans la version Silverlight, mais pas dans la version WPF.

Une autre différence est que si vous nommez le wrappeur CLR avec un autre nom que celui de la dépendency property (disons PlanetMass), vous aurez une exception au lancement de votre application WPF puisque WPF va chercher une dependency property du nom de PlanetMass, et celle-ci n'existe pas (elle s'appelle Mass). Avec Silverlight par contre, vous ne pourrez pas avoir d'exception si le code a compilé, puisque si le code a compilé, c'est que la propriété CLR utilisée dans le XAML existe, et c'est toujours cette propriété CLR qui sera utilisée.

Je dirais presque que le comportement de Silverlight est le plus naturel, puisque lorsqu'on tape du XAML, l'intellisense se base sur la déclaration de la propriété CLR (et pas sur la déclaration de la dependency, puisque celle-ci est déclarée par un appel à DependencyProperty.Register, ce qui n'est pas détectable par une analyse statique du code).

Espérons que ces différences s'effaceront avec les prochaines versions de Silverlight, mais la similarité des deux API est déjà relativement impressionnate.

Publié lundi 10 mars 2008 15:32 par RaptorXP
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: Toujours des différences de comportement entre WPF et Silverlight

 <p>Je ne suis pas un expert WPF mais dans "WPF Unleashed", il est clairement indiqué que les set/get des dependency properties sont shortcuttés et qu'il faut donc s'interdire d'y ajouter du code.</p>

<p>J'ai trouvé cela un peu étonnant. De mon point de vue:</p>

<ul>

<li>soit on joue le jeu de "on ne rajoute pas de couche de magie au CLR/Langages pour implémenter les nouvelles notions" et dans ce cas on utilise les set/get comme tout le monde (pas d'optimisation magique)</li>

<li>soit on ajoute cette notion dans le CLR (par de nouveau mots clé par exemple) et l'instance statique du DependencyProperty n'apparait pas.</li></ul>

<p>On peut comprendre que Silverlight n'ai pas la même politique en matière d'optimisation (et c'est encore une beta). Il est en effet souhaitable que les deux modèles fusionnent mais vers quoi? Le mode WPF est-il pérène ou ne s'agit-il que d'une astuce pour accélérer les premières versions de WPF?</p>

<p>Je trouve aussi que le modèle Silverlight est plus en adéquation avec le type d'implémentation choisie.</p>

mardi 11 mars 2008 11:40 by MuiBienCarlota

# re: Toujours des différences de comportement entre WPF et Silverlight

En fait, les dependency properties ne sont pas qu'une optimisation magique, elles rendent possible les animations, mais surtout le binding, la notification de modifications ou les propriétés attachées, qui seraient impossible à faire avec des propriétés CLR classiques (et d'autres choses).

D'un autre coté, le fonctionnement des dependency properties est un peu trop compliqué pour l'inclure dans le "noyau" du langage (par exemple ce systeme est juste trop lourd -et innutile- pour des appareils mobiles qui font tourner le Compact Framework).

Certe, on peut s'interdire de mettre du code dans les accesseurs CLR, mais cette différence de comportement pose aussi d'autres problèmes, par exemple. Supposons que tu as un propriété CLR classique qui s'appelle Mass, et que pour une raison quelconque, tu as une dependency property du meme nom (Je suis d'accord, c'est chercher les ennuis, mais c'est possible). Tu veux utiliser la propriété CLR depuis le code pour changer et acceder au champ CLR (c'est bien ce qui se passe depuis WPF et Silverlight). Par contre, tu veux qu'en utilisant Mass depuis le XAML, cela refere à la dependency property. C'est bien le comportement qu'on a avec WPF. Par contre, avec Silverlight, c'est le champ CLR qui va etre refere, donc on a un changement de comportement complètement invisible entre les deux versions.

mardi 11 mars 2008 16:29 by RaptorXP

# re: Toujours des différences de comportement entre WPF et Silverlight

J'avais très bien compris le fonctionnement des Dependency Properties. Je parlais uniquement du warning en page 53 de "WPF Unleashed":

".NET property wrappers are bypassed at run-time when setting dependency

properties in XAML!

Although the XAML compiler depends on the property wrapper at compile-time, at run-time

WPF calls the underlying GetValue and SetValue methods directly! Therefore, to maintain

parity between setting a property in XAML and procedural code, it’s crucial that property wrappers

do not contain any logic in addition to the GetValue/SetValue calls. If you want to add

custom logic, that’s what the registered callbacks are for. All of WPF’s built-in property wrappers

abide by this rule, so this warning is for anyone writing a custom class with its own

dependency properties."

Les set/get sont bypassés en WPF et pas en Silverlight...

lundi 17 mars 2008 22:52 by MuiBienCarlota
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01