2009-01-27 11 views
1

Je suis conscient que dans WPF, vous voulez garder les tailles de contrôles aussi flexibles que possible afin qu'ils puissent circuler et se développer en fonction de leur contexte (comme en CSS).Meilleures pratiques pour les tailles codées en dur dans XAML

Mais la plupart des exemples de code que je rencontre sont des tailles difficiles de codage comme les hauteurs dans cet exemple:

<Grid.ColumnDefinitions> 
    <ColumnDefinition Width="0.5*"/> 
    <ColumnDefinition Width="0.5*"/> 
</Grid.ColumnDefinitions> 
<Grid.RowDefinitions> 
    <RowDefinition Height="31"/> 
    <RowDefinition Height="31"/> 
    <RowDefinition Height="31"/> 
</Grid.RowDefinitions> 

est-ce pas l'attribution d'une hauteur de « 31 » à chaque ligne une mauvaise pratique qui devrait ne pas être émulé? Ou y a-t-il une raison à cela? Ou pourrait-il être que les auteurs créent ces exemples en mode design et ne nettoient pas les hauteurs codées en dur.

Quelqu'un a-t-il des bonnes pratiques concernant le dimensionnement des éléments (notamment en ce qui concerne l'utilisation de la syntaxe *) que les personnes débutant avec XAML peuvent suivre pour développer de bonnes habitudes dès le départ?

Répondre

1

De manière générale, il est recommandé d'utiliser des tailles dynamiques dans XAML car, comme vous le dites, le concept de WPF doit être indépendant des dimensions fixes. Dans votre exemple, je ne sais pas si cela est souhaité par l'auteur, rappelez-vous qu'il existe encore des cas impliquant des valeurs codées en dur (peut-être une barre de menus personnalisée ou un panneau que vous souhaitez conserver cohérent dans sa taille). La notation "2 *" signifie que la valeur sera deux fois la valeur des autres colonnes et donc, l'utilisation de la notation en étoile dans chaque colonne n'est pas très utile. Si vous cherchez des exemples, je peux vous adresser à ces twosites (mais si vous recherchez sur google pour "WPF star size" ou quelque chose comme ça vous en trouverez d'autres). De plus, si vous cherchez un très bon livre sur WPF, je peux certainement vous diriger vers Windows Presentation Foundation by Adam Nathan. C'est l'un de mes préférés, il est bien écrit, plein d'exemples colorés et couvre tous les aspects de WPF.

1

Il est préférable dans la plupart des cas d'utiliser des tailles dynamiques, sauf dans certains cas, comme l'a noté Stefano. Vous devriez vous rappeler que WPF est une technologie relativement nouvelle et que beaucoup de gens essaient de l'apprendre. Habituellement, lors de l'apprentissage d'une nouvelle technologie, les gens commencent par faire ce qu'ils savent (par exemple écrire en C# comme si c'était Java) et ensuite commencer à écrire le code de la manière "correcte" seulement après avoir appris un peu. Toujours prendre des messages de blog avec un grain de sel.

Cependant, à partir du code que vous avez posté, je suppose qu'ils ont utilisé Blend pour créer le XAML. Il fait toujours des choses idiotes comme ajouter des hauteurs de rang et faire les deux colonnes "0.5 *".

0

Parfois, vous ne pouvez pas échapper au dimensionnement explicite, en particulier lorsque vous travaillez avec des ressources de concepteur qui sont généralement converties en chemins de taille dans un outil tel que Expression Design. Lorsque vous souhaitez mettre en forme un contrôle avec un dimensionnement explicite, puis retourner et travailler avec comme un objet de taille dynamique, vous devez utiliser la Viewbox. Dans WPF, l'encapsulation d'un contrôle de taille dans une Viewbox prend en charge l'exécution dynamique des transformations afin qu'elles évoluent correctement. Cela a probablement une implication sur les performances, mais je ne sais pas à quel point c'est pire que de définir dynamiquement les tailles. Dans Silverlight, il n'y a pas de Viewbox prête à l'emploi, mais vous pouvez utiliser le Viewbox prototype de Silverlight Toolkit pour vous offrir une expérience équivalente.

Questions connexes