2.5Events & WLangage processes
The essentials in 30 seconds
- WinDev works through events: code is not executed from start to finish, it is triggered in reaction to an action (clicking, opening, modifying); these blocks are called processes.
- Each element has its list of events: window (global declarations, initialisation, closing), button (click), input control (entry, exit, modification), table (row selection/display).
- Place each process in the right place and keep events short by delegating logic to named procedures; beware of cascade effects.
Running mini-case — Yacine puts the code in the right place
Yacine, a WinDev developer at an SME trading electrical equipment in Oran, is working on the order-entry window of the management application. He must understand which code runs when. He writes data loading and screen preparation in the window's initialisation, and cleanup in the closing event. He places the quantity input check in the relevant control's Exit event — for immediate feedback to the user — and not in the click of the Valider button. The button click itself stays short: it orchestrates and delegates business logic (total calculation, stock check) to a reusable named procedure. Finally, he is wary of cascade effects: code that modifies a control can trigger its modification event.
Self-contained case for this section: it returns in the course, diagram, script and 48h challenge of section 2.5.
1. Triggered code, not linear
WinDev works through events: code is not executed from start to finish like a script, it is triggered in reaction to something (the user clicks, a window opens, a value changes). Understanding which code runs when is indispensable — it is the number-one source of confusion for beginners. Each element has a list of events where you write code, called processes.
2. The most used processes
For a window: global declarations (shared variables, executed first), initialisation (on opening: load data, prepare the screen), closing (cleanup, checks before leaving). For a button: click (the action to execute). For an input control: entry (the control takes focus), exit (you leave it — ideal for checking input), modification (the content changes). For a table: row selection and display. The execution order: global declarations, then initialisation, then events as actions occur.
3. Little code, in the right place
Good practices: put little code in events and delegate to named procedures (business code must not live in a button, otherwise it is neither reusable, nor testable, nor maintainable); write each process in the right place (an input check goes in the control's exit, not in the click of the Valider button); and beware of cascade effects (code that modifies a control can trigger that control's modification event).
🔎 Concrete example — 🔎 Concrete example — Where should the input check go?
The right place makes the difference: Yacine places the check in the control's exit.
// Initialisation of window FEN_SaisieCommande
FiltreStocks() // load / prepare the screen
// Exit of control SAI_Quantite -> immediate input check
SI SAI_Quantite <= 0 ALORS
Info("La quantite doit etre positive")
RETOUR
FIN
// Click on button BTN_Valider -> short, it DELEGATES
ValiderCommande() // business logic in a named PROCEDURE
Reading : initialisation = load; control exit = check
Reflex : short events, business logic in PROCEDURESReading: the input check lives in the control's exit (immediate feedback), not in the click of the Valider button.
Lesson: the event orchestrates and delegates to a named procedure: business code remains reusable, testable and maintainable.
Section vocabulary
- Event / process
- Code is not linear: it is triggered in reaction to an action (click, opening, value change). These blocks are called processes.
Simple example: Yacine writes the click of the order's Valider button.
What it is not: a script executed from start to finish, only once.
Reflex: react to an action → an event, therefore a process.
- Global declarations
- The process executed first for a window: you declare the variables shared by the whole window there.
Simple example: Yacine declares the current order number there.
What it is not: initialisation, executed afterwards
Reflex: variables shared by the window → global declarations.
- Initialisation / Closing
- Initialisation runs when the window opens (load data, prepare the screen); closing when leaving (cleanup, checks).
Simple example: Yacine loads the catalogue in initialisation.
What it is not: a validation button click.
Reflex: when opening or leaving → initialisation / closing.
- Entry / Exit / Modification
- The processes of an input control: entry (taking focus), exit (leaving it — ideal for checking input), modification (the content changes).
Simple example: Yacine checks the quantity in the control's exit.
What it is not: a check placed in the click of the Valider button.
Reflex: check input → the control's exit.
- Cascade effects
- Code that modifies a control can trigger that control's modification event, causing unexpected chains (or even loops).
Simple example: Yacine anticipates that assigning SAI_Total triggers its modification.
What it is not: an event totally isolated from the rest of the window.
Reflex: modify a control by code → think about cascade effects.
In practice — In practice — Putting your code in the right place
- Open a window's list of processes and note the order: global declarations, then initialisation, then events as actions occur, like Yacine.
- Write data loading and screen preparation in the window's initialisation.
- Place input checks in the relevant control's exit (not in the click of the Valider button) for immediate feedback to the user.
- Keep events short: delegate business logic to named procedures, and beware of cascade effects when code modifies a control.
Step-by-step script — place your code like Yacine (4 min)
1) Open a window and display its list of processes (global declarations, initialisation, closing). 2) Put data loading in initialisation. 3) Place the input check in the relevant control's exit. 4) Keep the Valider button click short: it calls a named procedure. 5) Test the programmatic modification of a control and observe the cascade effect.
Golden rule: little code in events, and business code in reusable procedures.
Copy-paste template — where to put which process
WINDOW : Global declarations -> Initialisation -> ... -> Closing
BUTTON : Click (short, it ORCHESTRATES and delegates)
FIELD : Entry / EXIT (= check input) / Modification
TABLE : Row selection / row display
Order : globals -> initialisation -> events as actions occur
Rules : (1) little code in events
(2) business logic in named PROCEDURES
(3) beware of CASCADE EFFECTSInitialisation
Yacine loads the catalogue and prepares the screen when the window opens.
Check on exit
Yacine checks the quantity in the control's exit, for immediate feedback.
Click that delegates
The click of the Valider button calls the ValiderCommande() procedure instead of containing everything.
Cascade effect
Yacine anticipates that assigning SAI_Total triggers the control's modification event.
✓ Best practices
- Put little code in events, delegate to procedures.
- Write the input check in the control's exit.
- Beware of cascade effects.
✗ Common pitfalls
- Putting all the business logic in a button click.
- Checking input in the Valider click rather than on control exit.
- Ignoring cascade effects when modifying by code.
Key takeaways
- WinDev works through events: code is triggered, not executed linearly.
- Essential processes: window (globals, initialisation, closing), button (click), field (entry, exit, modification), table (row).
- Short events + business logic in named procedures (reusable, testable, maintainable).
- Place each process in the right place and beware of cascade effects.
48h challenge — apply it tomorrow
Like Yacine, take a window in your application and move a field's input check from the click of the Valider button to the field's exit. Then keep the button click short by delegating logic to a named procedure, then cause a control modification by code to observe a cascade effect. Explain in one sentence why business logic must not live in a button.
- I know which process runs at which moment (event order).
- I place each process in the right place (check on control exit).
- I keep events short and delegate to named procedures.
Frequently asked questions
Why should you not write all the business logic in a button click?
Because that code is neither reusable (the same rule is used in other screens, reports, imports), nor testable, nor maintainable. The event must orchestrate and delegate to named procedures, where the shared business code lives.
Where should an input check go: in the Valider button or in the field?
In the relevant control's exit: the user gets immediate feedback at the moment they leave the control. Placing it in the Valider button click delays the check and mixes interface validation with the validation action.
Why should you not write all the business logic in a button click?