Pourquoi WPF XAML Intellisense n'affiche que les champs avec des accesseurs publics?

Question

Je me demande pourquoi mon Visual Studio 2017 Intellisense affiche uniquement les champs avec getter public. Dans ce cas particulier, des champs statiques avec getter public car j'essaie de charger dans le contenu WPF des champs statiques/constants.

Comme vous pouvez le voir dans le code ci-dessous j'ai ajouté trois différents champs à App classe, mais un seul (StaticGetterName) est représentée. Ce qui est drôle, c'est que ces deux autres champs (StaticField & ConstantName) fonctionnent bien si je le saisis sans erreur dans l'orthographe. Le projet génère et exécute avec succès l'un de ces trois champs de la classe App.

J'ai déjà essayé avec d'autres espaces de noms, d'autres classes, essayé d'ajouter static mot-clé à la déclaration de classe - pas de changement jusqu'à présent. Aussi partial mot-clé n'est pas le problème.

Ce serait bien si j'étais sur le point d'écrire des classeurs. Montrer seulement des suggestions avec le getter public prendrait alors tout son sens. Mais quand il s'agit de tous les types de champs statiques? Pas trop. J'ai vu d'autres questions, j'ai donc déduit qu'il y a encore quelques bugs autour de XISL Intellisense, mais pour clarifier - ce n'est pas le scénario où Intellisense ne fonctionne pas. En effet cela fonctionne, il me semble qu'il ne montre pas toutes les autocomplétions possibles.

App.xaml.cs

namespace DSIK.ClientApp 
{ 
    using System.Windows; 

    public partial class App : Application 
    { 
     public const string ConstantName = "Client"; 

     public static string StaticField = ConstantName; 

     public static string StaticGetterName => ConstantName; 
    } 
} 

MainWindow.xaml

<Window x:Class="DSIK.ClientApp.MainWindow" 
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
     xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
     xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
     xmlns:local="clr-namespace:DSIK.ClientApp" 
     Title="{x:Static local:App.StaticGetterName}" Height="460" Width="570"> 
    <Grid> 

    </Grid> 
</Window> 

Answer 1

Je suis court, parce que le système de type XAML et modèle de schéma ne dispose que d'un concept de propriétés. Il n'y a pas de concept de champs. Le contexte de schéma par défaut aurait pu être fait pour traiter les champs CLR comme des propriétés Xaml, mais cela n'a jamais été fait. J'imagine qu'il n'y avait aucune raison, car les champs non-finaux publics sont généralement déconseillés dans .NET.

Le modèle de type Xaml n'a pas non plus de concept de niveaux de protection. C'était probablement une décision de conception délibérée. Tous les membres qui peuvent être déclarés dans le balisage Xaml doivent être publics. Il est logique que Xaml (ou Baml) soit analysé lors de l'exécution, et Xaml peut exister entièrement en dehors du domaine des projets et des assemblages, donc il n'y a pas de moyen clair et cohérent de traiter les membres, par exemple. Et la construction d'objets à partir de Xaml ne se produit pas dans le contexte d'une instance de l'objet construit. En d'autres termes, Xaml crée des objets à partir du en dehors de, de sorte qu'il ne peut pas non plus prendre en charge les membres private ou protected.

Enfin, les constantes et les champs sont un peu différents. Même si les champs publics sont mappés aux propriétés Xaml, il n'y a aucune raison de mapper les constantes, car elles ne peuvent pas être définies dans Xaml. La même chose s'applique pour les champs en lecture seule, tout comme pour les propriétés en lecture seule (ou les propriétés sans setters publics).