L'ANCRAGE définit comment chaque champ réagit au REDIMENSIONNEMENT de la fenêtre (s'étirer, se déplacer, rester fixe) ; sans lui, une fenêtre agrandie affiche des champs figés dans un coin avec un grand vide — ce qui fait immédiatement « application bâclée ». Le problème que l'ancrage résout : (1) Une fenêtre WinDev est dessinée à une taille donnée. Mais l'utilisateur peut l'AGRANDIR, la maximiser, ou l'ouvrir sur un écran de résolution différente. (2) Sans ancrage, les champs gardent leur position et leur taille d'origine : agrandir la fenêtre ne fait qu'ajouter du vide à droite et en bas, tandis que les champs restent tassés en haut à gauche. La table qui pourrait afficher trente lignes en affiche toujours dix. (3) C'est l'un des défauts les plus visibles d'une application mal finie. Ce que permet l'ancrage : (1) ÉTIRER un champ : une TABLE ou un champ mémo qui grandit avec la fenêtre — c'est le cas le plus utile, car l'utilisateur gagne réellement de la place utile (plus de lignes visibles). (2) DÉPLACER un champ : des boutons de validation en bas à droite restent collés au coin quand la fenêtre s'agrandit. (3) FIXER un champ : un en-tête ou un libellé qui ne bouge pas. (4) Combinaisons : un champ peut s'étirer en largeur mais rester fixe en hauteur, etc. Comment bien l'utiliser : (1) Identifiez le champ PRINCIPAL de la fenêtre : celui qui doit profiter de l'espace supplémentaire (le plus souvent une TABLE, une liste ou une zone de texte long). Faites-le s'étirer en largeur ET en hauteur. (2) Les BOUTONS d'action (Valider, Annuler) placés en bas : ancrez-les pour qu'ils se DÉPLACENT vers le bas (et éventuellement la droite) et restent visibles. (3) Les champs de saisie courts (une date, un code) n'ont généralement pas besoin de s'étirer : les élargir démesurément est inesthétique et inutile. (4) Les barres d'en-tête ou de recherche en haut : souvent étirées en largeur, fixes en hauteur. (5) TESTEZ systématiquement : agrandissez, maximisez, réduisez la fenêtre en mode test et vérifiez que tout reste cohérent et lisible. C'est le seul moyen de valider vos réglages. (6) Pensez aux différentes RÉSOLUTIONS d'écran de vos utilisateurs. Les erreurs classiques : (1) Ne rien ancrer du tout (le défaut le plus fréquent). (2) Tout ancrer en étirement, y compris les petits champs, ce qui donne des zones de saisie absurdement larges. (3) Oublier les boutons, qui disparaissent hors de la zone visible ou flottent au milieu. (4) Ne jamais tester le redimensionnement. (5) Empêcher purement et simplement le redimensionnement pour éviter le problème — solution de facilité qui frustre l'utilisateur, surtout sur les fenêtres à listes. En résumé : l'ANCRAGE définit le comportement de chaque champ quand la fenêtre est redimensionnée — s'ÉTIRER, se DÉPLACER ou rester FIXE — et il est indispensable parce qu'une fenêtre sans ancrage, une fois agrandie, laisse tous les champs figés en haut à gauche dans un grand vide inutile : l'utilisateur ne gagne rien à maximiser, et l'application paraît bâclée. La bonne méthode : faites ÉTIRER le champ principal qui doit profiter de l'espace (typiquement une TABLE, une liste ou un champ mémo — l'utilisateur voit alors davantage de lignes), faites se DÉPLACER les boutons d'action pour qu'ils restent en bas à droite, laissez FIXES les petits champs de saisie (une date élargie sur tout l'écran n'a aucun intérêt), et surtout TESTEZ en agrandissant, maximisant et réduisant la fenêtre. Évitez les deux extrêmes : ne rien ancrer, ou tout étirer. Et ne bloquez pas le redimensionnement pour contourner le problème : c'est frustrant pour l'utilisateur.

Le NOMMAGE explicite rend le code WLangage lisible et maintenable (c'est par le nom qu'on manipule un champ), et l'ORDRE DE TABULATION conditionne la VITESSE de saisie au clavier — deux détails qui distinguent une application professionnelle d'une application amateur. Pourquoi le NOMMAGE compte : (1) C'est par le NOM qu'on manipule un champ en WLangage. Écrire « SAI_NomClient = Client.Nom » est immédiatement compréhensible ; écrire « SAI_Sans_nom1 = Client.Nom » ne veut rien dire. Le code se lit des dizaines de fois après avoir été écrit une fois. (2) MAINTENANCE : six mois plus tard (ou pour un collègue), un code aux noms parlants s'explique tout seul. Des noms génériques obligent à retourner voir la fenêtre pour comprendre de quoi on parle. (3) Moins d'ERREURS : avec des noms explicites, on repère immédiatement qu'on manipule le mauvais champ. (4) Recherche facilitée : chercher toutes les utilisations de « SAI_NomClient » dans le projet donne un résultat exploitable. (5) La CONVENTION habituelle utilise un PRÉFIXE par type de champ (SAI_ pour une saisie, BTN_ pour un bouton, TABLE_ pour une table, COMBO_, LIB_…) suivi d'un nom métier clair. L'important est d'être COHÉRENT dans tout le projet — et si vous êtes en équipe, d'adopter la même convention. Pourquoi l'ORDRE DE TABULATION compte : (1) La saisie au CLAVIER est la norme en gestion. Un opérateur qui saisit des centaines de lignes par jour ne lâche pas le clavier pour la souris : il enchaîne les champs avec la touche Tab. (2) Un ordre incohérent ruine la productivité : si Tab saute du nom au code postal, puis remonte au prénom, la saisie devient un supplice et génère des erreurs. C'est l'une des plaintes les plus fréquentes des utilisateurs. (3) L'ordre doit suivre l'ordre LOGIQUE et VISUEL de la fenêtre : de haut en bas, de gauche à droite, groupe par groupe. (4) Attention : l'ordre de tabulation ne correspond pas automatiquement à la position visuelle — surtout après avoir déplacé, ajouté ou supprimé des champs. Il faut le VÉRIFIER (l'éditeur permet de le visualiser et de le modifier). (5) Pensez aussi à EXCLURE de la tabulation les champs non saisissables. Les bonnes pratiques associées : (1) Nommez les champs dès leur création (ne remettez pas à plus tard : personne ne renomme cinquante champs après coup). (2) Vérifiez l'ordre de tabulation à la fin de la conception de chaque fenêtre, et RETESTEZ après toute modification de la disposition. (3) Testez une saisie complète UNIQUEMENT au clavier : c'est le vrai test. (4) Prévoyez les raccourcis utiles (validation par Entrée, annulation par Échap) — le confort de saisie est un critère de qualité majeur en gestion. En résumé : soignez le NOMMAGE parce que c'est par le nom que vous manipulez chaque champ en WLangage — un code écrit une fois est relu des dizaines de fois, par vous-même des mois plus tard ou par un collègue : « SAI_NomClient » s'explique seul, « SAI_Sans_nom1 » oblige à rouvrir la fenêtre pour comprendre. Adoptez une CONVENTION de préfixes par type (SAI_, BTN_, TABLE_…) suivie d'un nom métier, et soyez cohérent dans tout le projet. Soignez l'ORDRE DE TABULATION parce que la saisie au CLAVIER est la norme dans les applications de gestion : un opérateur enchaîne les champs avec Tab sans toucher la souris, et un ordre incohérent (qui saute d'un champ à l'autre au hasard) détruit la productivité et provoque des erreurs. L'ordre doit suivre l'ordre visuel et logique, il ne se met PAS à jour tout seul quand on déplace des champs, et le seul vrai test consiste à saisir une fiche complète uniquement au clavier. Ces deux « détails » sont exactement ce qui sépare une application professionnelle d'une application amateur.