AIDE-MEMOIRE WINDEV - GUIDINEE.COM
Reperes a garder sous la main pendant le projet fil rouge.
WinDev = Atelier de Genie Logiciel (PC SOFT) pour applications de GESTION. Tout integre : WLangage + HFSQL + editeurs (fenetres, etats) + debogueur + deploiement.
/!\ Produit COMMERCIAL (licence ; version d'essai gratuite limitee). Une version MAJEURE par an. Conditions et tarifs VARIENT selon les pays : voir les sources officielles PC SOFT.

=== VOCABULAIRE CLE (specifique WinDev) ===
- ANALYSE = description de la STRUCTURE des donnees (le modele de la base). Concept CENTRAL : tout en decoule.
- FICHIER = TABLE (au sens base de donnees). /!\ Pas un fichier du disque.
- RUBRIQUE = COLONNE / champ de table.  ENREGISTREMENT = LIGNE.  LIAISON = RELATION / cle etrangere.
- CHAMP = composant d'interface depose sur une fenetre (libelle, saisie, bouton, table, image...).
- TRAITEMENT = bloc de code rattache a un evenement.
- GDS = Gestionnaire De Sources.  RAD = Rapid Application Development.

=== ANALYSE (a soigner AVANT les fenetres) ===
- Demarche : ENTITES -> fichiers ; RUBRIQUES (nom + TYPE + taille) ; CLE PRIMAIRE (identifiant AUTOMATIQUE de preference) ; LIAISONS ; generer.
- TYPES : une date en type date, un montant en monetaire/numerique - JAMAIS en texte (sinon tris, calculs et controles faux).
- CLE PRIMAIRE : unique, TOUJOURS renseignee, surtout STABLE. Cle automatique >> cle metier (un code client change ; une cle ne doit pas changer). Bonne pratique : cle auto + code metier en rubrique avec contrainte d'UNICITE.
- LIAISON 1,n : un Client a PLUSIEURS Commandes ; le fichier cote « plusieurs » porte la cle etrangere. REGLES D'INTEGRITE (suppression interdite / en cascade) = protection de la coherence.
- NE JAMAIS REPETER une information (le nom du client uniquement dans Client). Seule exception : figer un HISTORIQUE (prix pratique au moment de la commande).
- /!\ Corriger l'analyse plus tard coute TRES cher (effet domino sur fenetres/requetes/etats + MIGRATION des donnees en production).

=== FENETRES & CHAMPS ===
- Dessin VISUEL (glisser-deposer). Champs : libelle, saisie, bouton, interrupteur, selecteur, combo, TABLE, image, onglet, looper.
- ANCRAGE = comportement au REDIMENSIONNEMENT : ETIRER le champ principal (souvent la TABLE -> plus de lignes visibles), DEPLACER les boutons d'action, laisser FIXES les petits champs. Sans ancrage : champs figes en haut a gauche = bacle.
- NOMMAGE EXPLICITE (SAI_NomClient, BTN_Valider) : c'est par le nom qu'on manipule le champ en WLangage. Convention de prefixes, coherente dans tout le projet.
- ORDRE DE TABULATION : doit suivre l'ordre visuel/logique. La saisie au CLAVIER est la norme en gestion -> tester une fiche complete SANS souris.
- CHARTE GRAPHIQUE : a choisir des la creation du projet. Ne stylisez pas les champs un par un : modifiez le STYLE (repercussion partout).

=== WLANGAGE (bases) ===
- Variables typees : MonTotal est un monetaire. Types : entier, reel, monetaire, chaine, booleen, date, heure, duree.
- Operateurs en francais : ET, OU, PAS. Structures : SI...ALORS...SINON...FIN ; POUR ; TANTQUE ; BOUCLE ; SELON.
- Qualite : NOMS clairs (pas x/tmp), INDENTATION, commenter le POURQUOI (pas le quoi), traitements COURTS, ZERO duplication.
- F1 = aide contextuelle riche, en francais, avec exemples. Reflexe a prendre tres tot.

=== DONNEES : CHAMPS LIES & FONCTIONS H ===
- CHAMP LIE a une rubrique -> FichierVersEcran() (afficher) et EcranVersFichier() (recuperer la saisie). Evite des dizaines d'affectations.
- Fonctions HFSQL (prefixe H) : HAjoute, HModifie, HSupprime, HLitPremier/Suivant/Precedent/Dernier, HLitRecherche, HRAZ.
- CYCLE FICHE : HRAZ -> saisie -> EcranVersFichier -> HAjoute (ou HModifie).
- /!\ TESTER HEnDehors apres TOUTE lecture/recherche AVANT d'exploiter le resultat : sinon on lit des valeurs residuelles, voire on MODIFIE le mauvais enregistrement (corruption silencieuse).
- ENREGISTREMENT EN COURS : c'est lui que HModifie/HSupprime affectent.

=== HFSQL, REQUETES, ETATS ===
- CLASSIC (fichiers sur disque/partage - monoposte ou petit reseau) vs CLIENT/SERVEUR (serveur central : multi-utilisateurs, volumes, securite, acces distants). Migration : analyse et code WLangage quasi INCHANGES.
- INDEX = l'optimisation la plus RENTABLE. Indexer : cles primaires, cles etrangeres (jointures !), rubriques de recherche et de tri frequentes. Ne pas tout indexer (cout a l'ecriture + espace).
- REQUETES : editeur VISUEL (genere le SQL) ou SQL direct. SELECT / FROM / WHERE / ORDER BY / JOIN / GROUP BY + agregats (SUM, COUNT, AVG, MIN, MAX). Requetes PARAMETREES = reutilisables.
- /!\ FILTRER COTE BASE (WHERE), pas en ramenant tout pour trier en WLangage. Erreur de perf n°1 : invisible sur un petit jeu de test, fatale en production.
- ETATS : blocs = DEBUT DE DOCUMENT / HAUT DE PAGE / CORPS (repete par enregistrement) / BAS DE PAGE / FIN DE DOCUMENT. RUPTURES = regroupements -> bloc de fin de rupture = SOUS-TOTAUX.
- /!\ Les donnees DOIVENT etre TRIEES sur la rubrique de rupture (ORDER BY), sinon groupes dupliques et sous-totaux faux. Preparer les donnees par une REQUETE plutot que tout calculer dans l'etat. Export PDF tres demande.
- TABLE FICHIER (liee, charge seulement l'affiche : performante sur gros volumes) >> TABLE MEMOIRE (remplie par code, tout en memoire). Piege classique : remplir une table memoire en parcourant un gros fichier.

=== EVENEMENTS (WinDev est evenementiel) ===
- FENETRE : Declarations globales (en 1er) -> Initialisation (charger/preparer) -> ... -> Fermeture.
- BOUTON : Clic.  CHAMP SAISIE : Entree / SORTIE (ideal pour CONTROLER) / Modification.  TABLE : selection/affichage de ligne.
- REGLE : peu de code dans les evenements -> deleguer a des PROCEDURES nommees. Le metier ne vit PAS dans un bouton (sinon : duplication, non testable, non reutilisable, couple a l'IHM).
- Controles de saisie : au fil de la saisie (sortie de champ, retour immediat) ET controle GLOBAL a la validation (dernier rempart : champs obligatoires, coherence entre champs). Ne jamais enregistrer des donnees invalides.
- /!\ Effets en CASCADE : modifier un champ par code peut declencher son evenement de modification.

=== STRUCTURER LE CODE ===
- PROCEDURE des que : DUPLICATION (signal n°1 : vous copiez-collez), LONGUEUR (> un ecran), COMPLEXITE. Une procedure = UNE responsabilite + nom explicite (verbe + objet).
- Portees : LOCALE (fenetre) / GLOBALE (projet) / COLLECTIONS DE PROCEDURES (par theme). Passez des PARAMETRES et renvoyez un RESULTAT ; limitez les VARIABLES GLOBALES (modifiables de partout = code imprevisible, dependances cachees, non reutilisable).
- Types avances : TABLEAU (indice), TABLEAU ASSOCIATIF (acces DIRECT par CLE - ideal pour les CACHES en memoire), STRUCTURE (regrouper des donnees), CLASSE (donnees + traitements + encapsulation + heritage).
- POO : utile pour regles metier riches, encapsulation, variantes, composants, equipe. PAS obligatoire : un procedural bien structure suffit souvent (l'enjeu reel = SEPARATION DES RESPONSABILITES).
- /!\ CONVERSIONS (texte <-> numerique <-> date) = source majeure de bugs. Dates jour/mois vs mois/jour = donnees fausses mais plausibles. Decimales virgule/point. CONTROLER AVANT de convertir ; prevenir a la source (champs types, masques, listes).
- REUTILISATION : MODELES de fenetres (modif repercutee partout), FENETRES INTERNES (bloc reutilisable), SUPERCHAMPS, COMPOSANTS (partage entre PROJETS : correction centralisee ; exige interface STABLE + doc + versions + tests).

=== ERREURS & DEBOGAGE ===
- 3 familles : COMPILATION / EXECUTION (QUAND EXCEPTION) / FONCTIONNELLE (le programme tourne mais le resultat est FAUX = la plus dangereuse).
- Ne presumez JAMAIS qu'une operation a reussi : testez les retours.
- Debogueur : POINTS D'ARRET, PAS A PAS, inspection des VARIABLES, pile d'appels + TRACE + journal.
- METHODE : REPRODUIRE (fiablement) -> ISOLER -> COMPRENDRE la cause REELLE (pas le symptome) -> CORRIGER + VERIFIER l'absence de regression. Ne jamais modifier au hasard.
- Utilisateur : message COMPREHENSIBLE et actionnable (jamais de code technique brut) ; detail technique dans le JOURNAL (diagnostic a distance). Ne jamais avaler une erreur en silence.

=== PRODUCTION : CLIENT/SERVEUR, SECURITE, DEPLOIEMENT, TESTS ===
- TRANSACTION = TOUT OU RIEN sur plusieurs ecritures liees (commande + lignes + stock). Sans elle : incoherence SILENCIEUSE decouverte des semaines plus tard. Transactions COURTES (jamais ouvertes en attendant une saisie).
- BLOCAGE / accès concurrents : eviter la « mise a jour perdue » (le 2e utilisateur ecrase le 1er). Pessimiste (verrouiller) ou optimiste (verifier au moment d'enregistrer). NE JAMAIS ecraser en silence. Tester A PLUSIEURS.
- SECURITE : Groupware Utilisateur (authentification, groupes, droits jusqu'aux champs). MOINDRE PRIVILEGE. Mots de passe JAMAIS en clair (hachage).
- /!\ La securite d'INTERFACE NE SUFFIT PAS (acces direct base, ODBC, copie de fichiers, exports, vos propres imports) -> securiser au niveau des DONNEES (droits serveur, contraintes analyse) + regles metier CENTRALISEES. Defense en profondeur. TRACER les operations sensibles.
- DEPLOIEMENT : executable + framework + acces natifs + images/etats/ressources + config. /!\ REGLE D'OR : TESTER sur une MACHINE VIERGE (VM), avec un compte STANDARD, toutes les fonctions dont l'IMPRESSION. 1re cause des deploiements rates.
- MISE A JOUR : SAUVEGARDER les donnees AVANT, tester sur une COPIE des donnees REELLES, planifier hors heures critiques, verifier apres, prevoir le RETOUR ARRIERE, informer les utilisateurs.
- TESTS AUTOMATIQUES : leur interet = detecter les REGRESSIONS (retester tout a la main est impossible). Cibler le coeur metier + CAS LIMITES (zero, vide, negatif, changement d'annee) + un test a CHAQUE bug corrige. /!\ Des tests obsolètes ignores sont PIRES que rien.

=== LA GAMME & LA DUREE ===
- WEBDEV (web) : meme WLangage, meme ANALYSE. /!\ Le code NAVIGATEUR est VISIBLE et MODIFIABLE (et l'utilisateur peut appeler le serveur directement) -> TOUTE validation qui compte se fait COTE SERVEUR. Apprendre : sessions, responsive, hebergement (domaine, HTTPS), performances.
- WINDEV MOBILE (Android/iOS) : ne PAS porter tel quel. Repenser PERIMETRE (quelques taches terrain), interface tactile, saisie (scan, listes, photo, GPS, signature). Difficulte majeure : HORS LIGNE + SYNCHRONISATION + CONFLITS (les reduire a la source en privilegiant l'AJOUT). Ne JAMAIS perdre une saisie terrain. Publication sur les STORES (regles evolutives).
- ECHANGES (API REST / fichiers) : GET/POST/PUT/DELETE, JSON, authentification. /!\ Secrets JAMAIS en dur. Le service SERA indisponible un jour : timeout, REPRISES, FILE D'ATTENTE, asynchrone, IDEMPOTENCE, VALIDER tout ce qui arrive, degradation controlee. JOURNALISER (seule preuve en cas de litige).
- GDS : referentiel + extraction/reintegration + HISTORIQUE + retour arriere. Utile MEME SEUL. En equipe : reintegrer SOUVENT, COMMENTER, conventions communes, tester avant, et COMMUNIQUER avant toute modification de l'ANALYSE. Sauvegarder le REFERENTIEL.
- PROGRESSER : documentation F1 + exemples livres + communaute + formations/certifications (/!\ variables selon pays/periodes). Travailler les FONDAMENTAUX TRANSFERABLES (SQL et modele relationnel, algorithmique, POO, architecture, tests, securite) et le METIER des utilisateurs.

RAPPELS
- ANALYSE d'abord (fichier=table, rubrique=colonne, liaison=relation). Types corrects. Cles automatiques. Ne rien repeter.
- Champs LIES + EcranVersFichier/HAjoute. TESTER HEnDehors systematiquement.
- FILTRER COTE BASE. INDEXER cles et rubriques de recherche. Table FICHIER sur gros volumes.
- Etats : TRIER avant les RUPTURES. Preparer les donnees par une REQUETE.
- Le METIER ne vit pas dans un bouton -> PROCEDURES. Zero duplication.
- TRANSACTIONS pour la coherence. Securite au niveau des DONNEES, pas seulement de l'IHM.
- Tester le deploiement sur MACHINE VIERGE. Sauvegarder AVANT toute mise a jour (et avant tout changement de version WinDev).
- BUT ULTIME : non « connaitre WinDev » mais LIVRER des applications JUSTES, ROBUSTES, MAINTENABLES et reellement UTILES.