Discussion :

[Tuttu]

Bonjour à tous,

Maintenant que je m'en sors un peu mieux avec le C#, j'aimerai pouvoir créer des interfaces graphiques un peu plus complexe sans pour autant passer tout de suite à WPF (Je vais m'y mettre mais je préfère d'abord m'améliorer en C# pur).

Ce que je souhaite dans l'immédiat, c'est faire une interface ayant ces propriétés :

• La taille au lancement est de 1024*768 pixels - Pour ça, pas de soucis.
• La taille de l'interface peut varier si l'utilisateur le souhaite. Pour celà, il a à sa disposition les fonctions classiques d'une fenêtre Windows. - Pour ça, j'ai un soucis : Comment faire pour que mon contenu s'adapte à la nouvelle taille de son conteneur ? TableLayoutPanel ?
• Le contenu sera beaucoup plus grand que les 768 pixels de base et sûrement plus grand que la taille du formulaire même redimensionné sur les plus grandes résolutions d'écrans. - Utiliser les propriétés d'AutoScroll me paraît être une bonne idée.

Dans la théorie, je vois plus ou moins comment faire. Mais dans la pratique, je n'arrive pas à m'en sortir et à me démêler de tout ça !
Existe-t-il un White Book ou quelque chose dans le genre qui référence les bonnes pratiques pour faire une interface sans que ça ne devienne un vrai bordel ?

Ma question peut paraître idiote mais je préfère partir tout de suite avec de bonnes bases pour avoir de "belles" interfaces plutôt que de perdre du temps et faire des trucs bidons. De plus, s'il vaut mieux que je passe à WPF pour me simplifier les choses, soit, je passerai à WPF. Et dans ce cas, j'espère pouvoir trouver des guides de bonnes pratiques.

[bacelar]

Pour la gestion du redimensionnement :
http://msdn.microsoft.com/fr-fr/libr...trol.dock.aspx

[Pol63]

si au final tu feras du wpf, autant ne pas perdre de temps sur les windows forms
l'interface ne se fait pas du tout de la meme manière, mais en plus le code a côté est différent

en windows forms, l'interface est gérée en grande partie par le c#, alors qu'en wpf bien codé, il n'y a que du traitement d'information en c# (ce qui parailleurs simplifie la lecture du code), l'interface et la liaison entre les interface et les données sont codés en xaml

[olibara]

Regarde les propriétés Anchor de tes control sur ta form !

[Louis-Guillaume Morand]

dock et anchor vont t'aider pour certains types d'affichage et de composant. Par contre, tu fais bien de le citer, le TableLayoutPanel, rarement utilisé, devrait être utilisé dans tout formulaire de saisie, SURTOUT si les labels sont localisables parce que selon une langue précise, le texte peut prendre deux lignes et c'est là que le tableLayoutPanel entre en jeu pour décaller automatiquement.

ensuite, sur la MSDN, il y a des guidelines de design d'application et les helpers de placement des composants depuis Visual 2005 t'aident dejà pas mal.
Après, il existe des règles comme TOUJOURS mettre le bouton annuler (ou autre) à la droite du bouton OK ou d'action.

faudrait que je retrouve le tuto, mais c'était sur 2003 et il était assez bien foutu

[Pol63]

Après, il existe des règles comme TOUJOURS mettre le bouton annuler (ou autre) à la droite du bouton OK ou d'action.

et pourquoi ?

[Louis-Guillaume Morand]

c'est ce qu'on appelle une convention
tu peux essayer toutes les applis que tu possèdes, tu verras que sur Windows, Linux, Iphone, firefox, IE, etc, vraiment tout ce que tu veux, le bouton d'action est toujours à gauche du bouton d'annulation.

si tu trouves une appli où ce n'est pas le cas, alors vraisemblablement, il y a d'autres problèmes d'ergonomie sur l'application car c'est une simple question de logique.
on lit de gauche à droite, et lorsque l'on cherche un bouton, on cherche une action précise: accepter, sauvegarder, etc. on sait ce qu'on doit faire. Il est donc logique que lorsqu'on parcours les boutons, l'on tombe d'abord (sens de lecture) sur le bouton qui fait ce que l'on cherche. tout simplement.
et si tu as plusieurs actions, la plus importante, est la plus à gauche. exemple, quand tu postes sur le forum, tu as d'abord "poster", en ensuite "visualiser".

[olibara]

Tout a fait !

Et j'ai fait passer plusieurs application grand public dans des laboratoire d'analyse d'ergonomie. C'est edifiant de voir combien la taille, la position la couleur des éléments, le choix eventuel du texte peuxent fortement influencer le comportement et la compréhension instinctive de l'utilisateur !

Edifiant aussi de voir que généralement à la moindre difficulté, le premier reflexe du dévelopeur sera toujours de penser que l'utilisateur est borné et qu'il ne fait pas l'effort nécessaire pour comprendre ce qu'on lui a mis devant les yeux !

Donc Tutu a bien raison de se préoccuper de son IHM

[Pol63]

c'est ce qu'on appelle une convention
tu peux essayer toutes les applis que tu possèdes, tu verras que sur Windows, Linux, Iphone, firefox, IE, etc, vraiment tout ce que tu veux, le bouton d'action est toujours à gauche du bouton d'annulation.

si tu trouves une appli où ce n'est pas le cas, alors vraisemblablement, il y a d'autres problèmes d'ergonomie sur l'application car c'est une simple question de logique.
on lit de gauche à droite, et lorsque l'on cherche un bouton, on cherche une action précise: accepter, sauvegarder, etc. on sait ce qu'on doit faire. Il est donc logique que lorsqu'on parcours les boutons, l'on tombe d'abord (sens de lecture) sur le bouton qui fait ce que l'on cherche. tout simplement.
et si tu as plusieurs actions, la plus importante, est la plus à gauche. exemple, quand tu postes sur le forum, tu as d'abord "poster", en ensuite "visualiser".

j'aurais une logique pas logique ?
(oui j'ai des boutons annuler à gauche du bouton valider, m'enfin ils sont gros et valider en vert et annuler en rouge, personne se trompe ...)

[Louis-Guillaume Morand]

c'est également mauvais, par rapport au tabindex. quant aux couleurs, rouge et vertes, de mémoire (pas sûr du tout donc), ca disait qu'il fallait les mettre pour afficher une information (genre une icone dans un statut, ou la couleur d'une case de saisie en cas d'erreur) mais pas sur les actions qui doivent être neutres et pas influencer l'utilisateur. Il pourrait cliquer sur le vert, simplement parce que le rouge fait "peur".

bref, je crois qu'on peut dire que tu fais n'importe quoi pol63

[Tuttu]

Bonjour à tous et merci pour vos réponses.

En effet, l'Anchor m'aident déjà, et j'avais oublié de le préciser. Merci de m'avoir réconforté dans leur utilisation. En revanche, je ne me suis pas servi de Dock, faut que je regarde comment il fonctionne.

Louis-Guillaume, si tu retrouves ton tuto, je suis preneur.
Mon plus gros soucis actuellement, c'est que je ne sais pas trop quel composant utiliser pour gérer l'agrandissement de la fenêtre.

Actuellement, si je pars sur un formulaire de taille fixe et que je clique sur le bouton "Agrandir", tous mes composants restent fixés en haut à gauche. Vous me direz que c'est normal, par défaut le Anchor est sur Top; Left.
Donc si je veux que tous mes contrôles suivent l'agrandissement de la fenêtre, je dois modifier un à un leur propriété Anchor ou bien il existe un composant magique (comme le TableLayoutPanel) qui peut m'y aider.
Si j'utilise un simple Panel qui lui va suivre le formulaire, les composants dans ce panel vont-ils suivre l'agrandissement ?

[olibara]

Oui tu dois definir l'anchor propre a chacun des composant : par forcément un a un, tu peux selectionner plusieurs éléments et définir l'anchanr de maniere groupée

Personnellement la seule fois ou j'ai utilisé un tablelayoutpannel, c'est pour le retirer d'une form ou il encombrait plutot que d'aider

Je n'ai donc pas d'avis réel sur l'intéret et la nécessité de son usage dans certains cas

[Tuttu]

Oui oui, quand je disais un par un, je ne comptais pas les faire un par un mais bien en les groupant.

Si c'est une solution, alors je n'ai plus qu'à faire mes tests. Merci.

[Pol63]

le tablelayoutpanel peut etre utile dans certains cas je pense
sinon il y a aussi le splitcontainer qui permet de redimensionné plusieurs controles (alors qu'avec anchor, en général on en défini qu'un par ligne/colonne qui s'agrandi)

[Louis-Guillaume Morand]

c'était pas celui là car le mien donnait des tailles de pixels et des trucs super précis, mais celui-là contient quelques conseils utiles
http://msdn.microsoft.com/en-us/library/aa511279.aspx

[Tuttu]

Merci beaucoup à tous. Merci pour le lien Louis-Guillaume.

Je passe en résolu et j'ouvrirai à nouveau le sujet si le besoin s'en fait sentir.