Comment déterminer de manière fiable si ce qui suit contrôtemplate code> est utilisé dans une application WPF? Le nom du fichier est 'CheckBtoxemplates.xaml' et se trouve dans un autre assemblage que l'application principale. Remarque, il n'y avait aucun résultat lorsque j'ai recherché le nom de fichier et la clé de ressource. De plus, la recherche de la solution pour une clé de ressources n'est pas fiable. Surtout, lorsqu'il y a cinq fichiers de dictionnaire de ressources contenant la même clé.
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mwt="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Luna">
<Style x:Key="invertedCheckBox"
TargetType="CheckBox">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="CheckBox"
...
5 Réponses :
Vous pouvez utiliser l'outil VisualStudio et "Rechercher dans les fichiers". Essayez de trouver la clé de style, par exemple invertedCheckbox code> dans une solution complète. Afin que vous puissiez déterminer où le style est utilisé. P>
Je l'ai déjà fait et je n'ai pas trouvé le nom de fichier. J'ai aussi cherché la "clé". Comment savoir si une case à cocher code> utilise ce style? C'est pourquoi j'ai posté les questions. J'ai besoin d'une manière fiable.
Trouver toutes les cases à cocher code> dans votre solution. Vérifiez si la case à cocher code> a des ensembles de propriétés de style sur style = "{staticresource invertedcheckbox}" code> Si vous ne trouvez rien, vous pouvez être sûr que ce style n'est pas utilisé.
Je l'ai fait et trouvé aucune utilisation. J'ai ensuite créé un projet de test et j'ai fait des tests. Il semble que si x: clé code> est défini et non utilisé, le style n'est pas utilisé. Il n'y a pas d'utilisation implicite, car une clé est toujours générée sur la base du
cibletype code>.
Oui. Savez-vous quelque chose sur le style implicite, explicite et par défaut?
Style explicite - La propriété de style est définie directement. Dans la plupart des scénarios, le style n'est pas défini en ligne, mais est également référencé en tant que ressource, par clé explicite.
Style implicite - La propriété Style n'est pas définie directement. Cependant, le style existe à un certain niveau dans la séquence de recherche de ressources (page, application) et est saisi à l'aide d'une clé de ressources correspondant au type que le style doit être appliqué.
Style par défaut - également appelé style de thème. La propriété de style n'est pas définie directement et se lira en fait comme null jusqu'à l'heure d'exécution. Dans ce cas, le style provient de l'évaluation thématique d'exécution faisant partie du moteur de présentation WPF. Pour les styles implicites non dans des thèmes, le type doit correspondre exactement - une classe dérivée de bouton de mybutton n'utilisera pas implicitement un style pour le bouton.
J'ai compris, mais je ne savais pas que x: clé code> si non défini serait créé à partir de
cibletype code>.
Je dois toujours déterminer fiable si un style est utilisé lorsqu'il est défini plusieurs fois.
Il y a quelques options que je peux penser: p>
La solution "Développement": Ceci inclut la recherche de chaque fichier de l'existence de la solution d'exécution: vous pouvez instancier chaque contrôle de la bibliothèque de classe et itérer sur chaque élément de celui-ci, en vérifiant le style La solution "Code": Vous pouvez créer votre propre classe statique de façade, c'est-à-dire un point d'entrée pour obtenir un style. Remarque Vous n'êtes pas autorisé à utiliser style = "{staticresource stylename}" code> ou quelque chose de similaire. Cela fonctionnera dans beaucoup de cas, mais n'est pas automatisé et non très fiable; P> Li>
actuellement attribué code>. Cela ne fonctionne que pour les styles étant défini immédiatement et non pendant les événements, etc. p> li>
style = "{staticresource stylename}" code> plus, mais
style = "{staticresource somestaticclass.stylename}" code>. Cela ne fonctionnera que lorsque vous avez une équipe de développement de qualité utilisée à cette méthode de travail. Vous pouvez compter le nombre de fois qu'un style est accessible sur la durée du programme. Si après beaucoup de temps, le style
code> n'a pas encore été utilisé, il est probablement candidat de se débarrasser de. P> li>
ul>
Intéressant. J'ai fait l'article 1, mais pas fiable, d'où la question. L'article n ° 3 est une bonne idée, mais cela couvrirait-il des cas où le style n'était pas défini explicitement? Pour l'article n ° 2, peut-être que Snoop peut faire cela?
Je n'ai pas pu trouver un moyen d'utiliser Snoop.
D'accord. Je ne suis pas si familier avec tout l'outillage WPF. Je vais jeter un oeil demain quand je suis au bureau.
Pardon. Jour stressé au bureau. Pas beaucoup de temps pour regarder cela.
Pas de problème. Je peux supprimer de manière fiable ce modèle de contrôle en raison de l'utilisation de x: clé code>. User2250152 Réponse et certaines expérimentations ont fourni une réponse fiable à ce cas spécifique. Pourtant, le problème existe toujours pour d'autres styles définis dans plusieurs fichiers.
Il peut être possible d'ajouter "propriété connectée" dans chaque style code> code>. Cette propriété attachée sera chargée une fois que style code> est chargé. Cela vous aiderait à éliminer certains des styles chargés implicitement, et si nécessaire, explicite aussi.
Restomer montre le code mort. Bien que son algorithme de détection n'est pas parfait, c'est un bon départ, vous permettant de sauter n'importe quel style qu'il apparaît comme utilisé. Pour tout style montré comme inutilisé, vous pouvez ensuite vérifier s'il n'est pas utilisé (ex. En recherchant la solution). P>
Cela fonctionne-t-il aussi pour les styles XAML? Ne pouvait pas le trouver.
Je ne pense pas que Resharper fonctionne. J'ai délibérément causé un style inutilisé et cela n'a donné aucune indication.
L'algorithme de détection n'est vraiment pas parfait, le dernier que je l'ai utilisé, il a cassé des styles qui étaient utilisés. Inutile de dire qu'ils n'auront jamais cela parfait. En ce qui concerne la question de l'OP, la réponse est non, il n'y a pas de manière fiable :-). C'est tout simplement pas possible, simple comme ça. Comme Patrick l'a dit, les styles peuvent être modifiés au moment de l'exécution lorsque des événements se produisent, lorsque des déclencheurs se produisent, etc., il est non déterministe.
@Chris: vrai. La classe de façade peut être la meilleure option après tout.
Une manière peu orthodoxe d'y arriver serait de créer une propriété attachée qui imprime qui utilise la commande ControlTemplate :) Pensez-y comme ceci:
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:mwt="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Luna"> <Style x:Key="invertedCheckBox" TargetType="CheckBox"> <Setter Property="Template"> <Setter.Value> <ControlTemplate TargetType="CheckBox"> <Border my:WhoIsMyDaddy="true" ...>
Intéressant. Le seul inconvénient est que vous devriez faire de l'exercice de la boîte à cocher.
Je devrais aller à chaque écran qui utilise une case à cocher code> pour utiliser (exercice) à chaque case à cocher pour voir si le modèle est utilisé. Correct?
Non! Si toutes vos cases à cocher utilisent le style InvertedCheckBox, ils initalisent tous la propriété attachée. Chaque case à cocher aura sa propre propriété Boolean Attachée. Lorsque vous définissez un point de séquence à l'intérieur du gestionnaire, vous verrez quand la case à cocher attache la propriété de dépendance. C'est ainsi que vous saurez si votre contrôleur de contrôle est utilisé.
basé sur ce que vous avez dit p>
Le nom du fichier est "Checkebébatsemplates.xaml" et se trouve dans un autre assemblage que l'application principale. Remarque, il n'y avait aucun résultat lorsque j'ai recherché le nom de fichier et la clé de ressource. P> blockQuote>
Vous pouvez être sûr que ce style n'est pas utilisé. Autant que je sache, il n'y a pas de chargement automatique de fichiers XAML (à l'exception des ressources d'application et des thèmes) Signifie qu'il n'ya aucun moyen de contrôler explicitement ou implicitement référence à ce style (qui semble être déchargé - sauf si vous avez du code derrière la magie Chargement de fichiers XAML de toute façon) P>
Au moment de l'exécution ou compilez-vous?
Soit. Les styles de l'application provoquent des problèmes. La première étape consiste à éliminer les styles morts. Je serais reconnaissant de tout moyen de le faire. Même un outil séparé aiderait.
@Patrickhofman; Je ne comprends pas.