Parce qu'une recherche peut ne RIEN trouver : sans ce test, votre code continue en exploitant des valeurs qui ne correspondent à aucun enregistrement réel — l'application affiche alors des données fausses ou se comporte de façon imprévisible, sans forcément planter. Ce que fait HEnDehors : (1) Après une lecture (HLitPremier, HLitSuivant…) ou une recherche (HLitRecherche), HEnDehors indique si l'on se trouve EN DEHORS du fichier, c'est-à-dire : aucun enregistrement ne correspond au critère, ou l'on a atteint la fin (ou le début) du parcours. (2) C'est le témoin de « il n'y a rien ici » — l'équivalent d'un résultat vide. Pourquoi l'oublier est dangereux : (1) Vous exploitez des données INEXISTANTES. Si la recherche échoue et que vous affichez quand même Client.Nom, vous affichez le contenu résiduel de la mémoire (souvent les valeurs du dernier enregistrement lu, ou des valeurs vides). L'utilisateur voit alors des informations qui ne correspondent à rien. (2) Pire : vous pouvez ÉCRIRE au mauvais endroit. Enchaîner un HModifie après une recherche infructueuse peut modifier un enregistrement qui n'était pas celui visé — une corruption silencieuse des données, le pire scénario possible. (3) Le bug est SOURNOIS : l'application ne plante pas, elle ment. Elle fonctionne parfaitement tant que les recherches aboutissent, et se met à produire des résultats faux dans les cas limites — précisément ceux qu'on teste le moins. (4) Ces défauts sont découverts tard, souvent par l'utilisateur, et sont pénibles à diagnostiquer. Comment faire correctement : (1) Testez IMMÉDIATEMENT après la lecture ou la recherche, avant toute exploitation du résultat. (2) Structure typique : rechercher, puis SI HEnDehors ALORS traiter le cas « non trouvé » (message clair à l'utilisateur, valeur par défaut, création d'un nouvel enregistrement…) SINON exploiter normalement les données. (3) Traitez explicitement le cas « rien trouvé » : ce n'est pas une anomalie, c'est un cas normal à prévoir (le client n'existe pas encore, la référence est erronée). Donnez un message UTILE à l'utilisateur plutôt que de laisser un écran vide inexpliqué. (4) Même logique dans les PARCOURS : la boucle de lecture s'arrête quand on est en dehors. (5) Cohérence : appliquez ce contrôle PARTOUT, systématiquement — c'est un réflexe, pas une option. Le principe général : (1) Ne SUPPOSEZ jamais qu'une opération sur des données a réussi : vérifiez. (2) C'est la même philosophie que la gestion des erreurs (niveau 3) : le code robuste prévoit les cas où les choses ne se passent pas comme espéré. (3) En gestion, la JUSTESSE des données prime sur tout : mieux vaut un message « client introuvable » qu'un affichage erroné. En résumé : testez SYSTÉMATIQUEMENT HEnDehors après toute lecture ou recherche parce qu'une recherche peut parfaitement ne rien trouver — et sans ce contrôle, le code poursuit son exécution en exploitant des valeurs résiduelles en mémoire qui ne correspondent à AUCUN enregistrement réel. Les conséquences vont de l'affichage de données fausses jusqu'au cas le plus grave : un HModifie ou un HSupprime appliqué au mauvais enregistrement, c'est-à-dire une corruption silencieuse des données. Le défaut est particulièrement sournois car l'application ne plante pas : elle fonctionne tant que les recherches aboutissent, puis ment dans les cas limites, ceux justement qu'on teste le moins. La bonne pratique : contrôler IMMÉDIATEMENT après la recherche, traiter explicitement le cas « non trouvé » (message clair, valeur par défaut ou création) et considérer ce test comme un réflexe permanent — au même titre que la gestion des erreurs. En gestion, la justesse des données prime sur tout.

Les CHAMPS LIÉS automatisent le transfert entre l'écran et les rubriques (via ÉcranVersFichier/FichierVersÉcran) — c'est rapide, sûr et à privilégier ; le code MANUEL (affectations une par une) reste utile pour les cas particuliers où l'écran ne reflète pas directement les données. Le fonctionnement des champs LIÉS : (1) On associe un champ d'écran à une rubrique de l'analyse dans les propriétés du champ (SAI_Nom ↔ Client.Nom). (2) FichierVersÉcran() remplit d'un coup TOUS les champs liés de la fenêtre avec les valeurs de l'enregistrement en cours. (3) ÉcranVersFichier() fait l'inverse : il recopie d'un coup toutes les saisies dans les rubriques, prêtes à être enregistrées. (4) On enchaîne ensuite HAjoute ou HModifie. Les AVANTAGES des champs liés : (1) RAPIDITÉ d'écriture : deux appels de fonction remplacent des dizaines de lignes d'affectation. Sur une fiche de trente champs, le gain est spectaculaire. (2) Moins d'ERREURS : pas de risque d'oublier un champ, d'inverser deux affectations ou de se tromper de rubrique — erreurs classiques et pénibles à repérer. (3) MAINTENANCE : ajouter une rubrique et son champ ne demande aucune modification du code de transfert. Avec des affectations manuelles, il faudrait penser à ajouter la ligne correspondante dans les deux sens (et l'oubli est fréquent). (4) Cohérence avec le RAD : les fenêtres générées automatiquement fonctionnent sur ce principe. (5) Code plus COURT et donc plus lisible. Quand le code MANUEL se justifie : (1) Transformation nécessaire entre l'affichage et le stockage : la donnée saisie n'est pas exactement celle qu'on enregistre (calcul, concaténation, conversion, normalisation d'un format). (2) Champs NON liés : zones de travail, filtres de recherche, totaux calculés, indicateurs — qui ne correspondent à aucune rubrique. (3) Contrôles ou règles métier à appliquer avant enregistrement (mais on peut aussi les faire en complément d'ÉcranVersFichier). (4) Données provenant de plusieurs fichiers ou d'une requête complexe, où la correspondance n'est pas directe. (5) Traitements par LOT, sans interface (import, calculs de masse) : là, il n'y a pas d'écran du tout, on manipule directement les rubriques. La bonne approche (combiner) : (1) Par DÉFAUT : champs LIÉS pour tout ce qui est saisie/affichage classique d'une fiche. C'est le mode normal en WinDev, et s'en priver serait renoncer à sa productivité. (2) En COMPLÉMENT : code manuel pour les cas particuliers — après ÉcranVersFichier, vous pouvez toujours affecter ou corriger une rubrique spécifique avant d'enregistrer. (3) Les deux approches COEXISTENT très bien : lier ce qui est direct, coder ce qui demande une transformation. (4) Gardez les CONTRÔLES de validité (données obligatoires, cohérence) avant l'enregistrement, quelle que soit la méthode. En résumé : les CHAMPS LIÉS associent un champ d'écran à une rubrique, permettant à FichierVersÉcran() et ÉcranVersFichier() de transférer d'un seul appel toutes les valeurs dans un sens ou dans l'autre — c'est plus RAPIDE à écrire (deux lignes au lieu de dizaines), moins SUJET AUX ERREURS (aucun champ oublié ni inversé), plus FACILE à maintenir (ajouter une rubrique ne demande aucune retouche du code de transfert) et cohérent avec le RAD. C'est donc le mode par DÉFAUT, et s'en passer reviendrait à renoncer à la productivité de WinDev. Le code MANUEL garde toute sa place pour les cas où l'écran ne reflète pas directement le stockage : transformations (calcul, conversion, formatage), champs non liés (filtres, totaux, zones de travail), données issues de plusieurs fichiers ou requêtes, et traitements par lot sans interface. Les deux se COMBINENT naturellement : liez ce qui est direct, complétez par du code pour les cas particuliers — typiquement en ajustant une rubrique après ÉcranVersFichier et avant HAjoute/HModifie. Dans tous les cas, gardez les contrôles de validité avant enregistrement.