2.5Événements & traitements WLangage
L'essentiel en 30 secondes
- WinDev fonctionne par événements : le code n'est pas exécuté du début à la fin, il est déclenché en réaction à une action (cliquer, ouvrir, modifier) ; ces blocs s'appellent des traitements.
- Chaque élément a sa liste d'événements : fenêtre (déclarations globales, initialisation, fermeture), bouton (clic), champ de saisie (entrée, sortie, modification), table (sélection/affichage de ligne).
- Placer chaque traitement au bon endroit et garder les événements courts en déléguant la logique à des procédures nommées ; se méfier des effets en cascade.
Mini-cas filé — Yacine place le code au bon endroit
Yacine, développeur WinDev dans une PME de négoce de matériel électrique à Oran, travaille sur la fenêtre de saisie des commandes de l'application de gestion. Il doit comprendre quel code s'exécute quand. Il écrit le chargement des données et la préparation de l'écran dans l'initialisation de la fenêtre, et le nettoyage dans la fermeture. Le contrôle de saisie de la quantité, il le place dans l'événement Sortie du champ concerné — pour un retour immédiat à l'utilisateur — et non dans le clic du bouton Valider. Le clic du bouton, lui, reste court : il orchestre et délègue la logique métier (calcul des totaux, contrôle du stock) à une procédure nommée réutilisable. Enfin, il se méfie des effets en cascade : un code qui modifie un champ peut déclencher son événement de modification.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 2.5.
1. Un code déclenché, pas linéaire
WinDev fonctionne par événements : le code n'est pas exécuté du début à la fin comme un script, il est déclenché en réaction à quelque chose (l'utilisateur clique, une fenêtre s'ouvre, une valeur change). Comprendre quel code s'exécute quand est indispensable — c'est la source de confusion n°1 chez les débutants. Chaque élément possède une liste d'événements où l'on écrit du code, appelés traitements.
2. Les traitements les plus utilisés
Pour une fenêtre : déclarations globales (variables communes, exécutées en premier), initialisation (à l'ouverture : charger les données, préparer l'écran), fermeture (nettoyage, contrôles avant de quitter). Pour un bouton : clic (l'action à exécuter). Pour un champ de saisie : entrée (le champ prend le focus), sortie (on le quitte — idéal pour contrôler la saisie), modification (le contenu change). Pour une table : sélection et affichage d'une ligne. L'ordre d'exécution : déclarations globales, puis initialisation, puis les événements au fil des actions.
3. Peu de code, au bon endroit
Bonnes pratiques : mettre peu de code dans les événements et déléguer à des procédures nommées (le code métier ne doit pas vivre dans un bouton, sinon il est ni réutilisable, ni testable, ni maintenable) ; écrire chaque traitement au bon endroit (un contrôle de saisie va dans la sortie du champ, pas dans le clic du bouton Valider) ; et se méfier des effets en cascade (un code qui modifie un champ peut déclencher l'événement de modification de ce champ).
🔎 Exemple concret — 🔎 Exemple concret — Où écrire le contrôle de saisie ?
Le bon endroit fait la différence : Yacine place le contrôle dans la sortie du champ.
// Initialisation de la fenetre FEN_SaisieCommande
FiltreStocks() // charger / preparer l'ecran
// Sortie du champ SAI_Quantite -> controle de saisie immediat
SI SAI_Quantite <= 0 ALORS
Info("La quantite doit etre positive")
RETOUR
FIN
// Clic du bouton BTN_Valider -> court, il DELEGUE
ValiderCommande() // logique metier dans une PROCEDURE nommee
Lecture : initialisation = charger ; sortie de champ = controler
Reflexe : evenements courts, logique metier dans des PROCEDURESLecture : le contrôle de saisie vit dans la sortie du champ (retour immédiat), pas dans le clic du bouton Valider.
Leçon : l'événement orchestre et délègue à une procédure nommée : le code métier reste réutilisable, testable et maintenable.
Vocabulaire de la section
- Événement / traitement
- Le code n'est pas linéaire : il est déclenché en réaction à une action (clic, ouverture, changement de valeur). Ces blocs s'appellent des traitements.
Exemple simple : Yacine écrit le clic du bouton Valider de la commande.
Ce que ce n'est pas : un script exécuté du début à la fin, une seule fois.
Réflexe : réagir à une action → un événement, donc un traitement.
- Déclarations globales
- Le traitement exécuté en premier pour une fenêtre : on y déclare les variables communes à toute la fenêtre.
Exemple simple : Yacine y déclare le numéro de commande courant.
Ce que ce n'est pas : l'initialisation, exécutée après
Réflexe : variables partagées par la fenêtre → les déclarations globales.
- Initialisation / Fermeture
- Initialisation s'exécute à l'ouverture de la fenêtre (charger les données, préparer l'écran) ; fermeture au moment de quitter (nettoyage, contrôles).
Exemple simple : Yacine charge le catalogue dans l'initialisation.
Ce que ce n'est pas : un clic de bouton de validation.
Réflexe : au moment d'ouvrir ou de quitter → initialisation / fermeture.
- Entrée / Sortie / Modification
- Les traitements d'un champ de saisie : entrée (prise de focus), sortie (on le quitte — idéal pour contrôler la saisie), modification (le contenu change).
Exemple simple : Yacine contrôle la quantité dans la sortie du champ.
Ce que ce n'est pas : un contrôle placé dans le clic du bouton Valider.
Réflexe : contrôler une saisie → la sortie du champ.
- Effets en cascade
- Un code qui modifie un champ peut déclencher l'événement de modification de ce champ, provoquant des enchaînements inattendus (voire des boucles).
Exemple simple : Yacine anticipe qu'affecter SAI_Total déclenche sa modification.
Ce que ce n'est pas : un événement totalement isolé du reste de la fenêtre.
Réflexe : modifier un champ par code → penser aux effets en cascade.
En pratique — En pratique — Placer son code au bon endroit
- Ouvrez la liste des traitements d'une fenêtre et repérez l'ordre : déclarations globales, puis initialisation, puis les événements au fil des actions, comme Yacine.
- Écrivez le chargement des données et la préparation de l'écran dans l'initialisation de la fenêtre.
- Placez les contrôles de saisie dans la sortie du champ concerné (pas dans le clic du bouton Valider) pour un retour immédiat à l'utilisateur.
- Gardez les événements courts : déléguez la logique métier à des procédures nommées, et méfiez-vous des effets en cascade quand du code modifie un champ.
Script pas-à-pas — placer son code comme Yacine (4 min)
1) Ouvrez une fenêtre et affichez sa liste de traitements (déclarations globales, initialisation, fermeture). 2) Mettez le chargement des données dans l'initialisation. 3) Placez le contrôle de saisie dans la sortie du champ concerné. 4) Gardez le clic du bouton Valider court : il appelle une procédure nommée. 5) Testez la modification programmatique d'un champ et observez l'effet en cascade.
Règle d'or : peu de code dans les événements, et le code métier dans des procédures réutilisables.
Modèle copier-coller — où mettre quel traitement
FENETRE : Declarations globales -> Initialisation -> ... -> Fermeture
BOUTON : Clic (court, il ORCHESTRE et delegue)
CHAMP : Entree / SORTIE (= controler la saisie) / Modification
TABLE : Selection de ligne / affichage de ligne
Ordre : globales -> initialisation -> evenements au fil des actions
Regles : (1) peu de code dans les evenements
(2) logique metier dans des PROCEDURES nommees
(3) se mefier des EFFETS EN CASCADEInitialisation
Yacine charge le catalogue et prépare l'écran à l'ouverture de la fenêtre.
Contrôle en sortie
Yacine contrôle la quantité dans la sortie du champ, pour un retour immédiat.
Clic qui délègue
Le clic du bouton Valider appelle la procédure ValiderCommande() au lieu de tout contenir.
Effet en cascade
Yacine anticipe qu'affecter SAI_Total déclenche l'événement de modification du champ.
✓ Bonnes pratiques
- Mettre peu de code dans les événements, déléguer à des procédures.
- Écrire le contrôle de saisie dans la sortie du champ.
- Se méfier des effets en cascade.
✗ Pièges fréquents
- Mettre toute la logique métier dans le clic d'un bouton.
- Contrôler une saisie dans le clic de Valider plutôt qu'en sortie de champ.
- Ignorer les effets en cascade lors d'une modification par code.
Points clés à retenir
- WinDev fonctionne par événements : le code est déclenché, pas exécuté linéairement.
- Traitements essentiels : fenêtre (globales, initialisation, fermeture), bouton (clic), champ (entrée, sortie, modification), table (ligne).
- Événements courts + logique métier dans des procédures nommées (réutilisable, testable, maintenable).
- Placer chaque traitement au bon endroit et se méfier des effets en cascade.
Défi 48h — appliquez demain
Comme Yacine, prenez une fenêtre de votre application et déplacez le contrôle de saisie d'un champ du clic du bouton Valider vers la sortie du champ. Gardez ensuite le clic du bouton court en déléguant la logique à une procédure nommée, puis provoquez une modification de champ par code pour observer un effet en cascade. Expliquez en une phrase pourquoi la logique métier ne doit pas vivre dans un bouton.
- Je sais quel traitement s'exécute à quel moment (ordre des événements).
- Je place chaque traitement au bon endroit (contrôle en sortie de champ).
- Je garde les événements courts et délègue à des procédures nommées.
Questions fréquentes
Pourquoi ne faut-il pas écrire toute la logique métier dans le clic d'un bouton ?
Parce que ce code n'est ni réutilisable (la même règle sert dans d'autres écrans, états, imports), ni testable, ni maintenable. L'événement doit orchestrer et déléguer à des procédures nommées, où vit le code métier partagé.
Où placer un contrôle de saisie : dans le bouton Valider ou dans le champ ?
Dans la sortie du champ concerné : l'utilisateur obtient un retour immédiat au moment où il quitte le champ. Le placer dans le clic du bouton Valider retarde le contrôle et mélange la validation d'interface avec l'action de validation.
Pourquoi ne faut-il pas écrire toute la logique métier dans le clic d'un bouton ?