1.2Windows & controls (user interface)
The essentials in 30 seconds
- Windows are drawn visually (drag and drop) and host controls: label, input, button, table, combo box, tab…
- Anchoring defines resize behavior: a control can stretch, move or stay fixed — without it, the interface looks sloppy.
- Name explicitly and mind the tab order: a control is handled by its name in WLangage, and the Tab order determines input speed.
Running mini-case — Yacine designs the “Fiche commande” window
Yacine now creates the interface of his trading application. He opens an empty window titled “Fiche commande” and drops controls onto it by drag and drop: a “Client” label, an input control, a table for the item lines, and “Valider” and “Annuler” buttons. He immediately renames each control explicitly: SAI_NomClient instead of SAI_Sans_nom1. Then he tests by enlarging the window: the table stays squeezed in the top left in a large empty space. So he sets the ANCHORING: the table stretches in width and height, the buttons move to the bottom, the label stays fixed. Finally he checks the TAB ORDER: the Tab key must go from name to phone, then to the items, in the logical input order. Yacine remembers: well-named controls, correct anchoring and a coherent Tab order make a professional interface.
Standalone case for this section: it returns in the course, diagram, script and 48h challenge of section 1.2.
1. Windows and their controls
WINDOWS form the application's interface: what the user sees and handles. In WinDev, they are drawn visually, without positioning code. CONTROLS are dropped onto them — WinDev's term for interface components.
The main ones: the label (fixed text), the input control, the button, the combo box, the tab, and above all the TABLE — a major control in management apps, displaying several records in rows and columns. Each control has a name and properties (description tabs).
2. Anchoring on resize
ANCHORING defines what happens to a control when the window is resized: stretch, move or stay fixed. Without anchoring, enlarging the window leaves the controls frozen in the top left in a large empty space — the most visible flaw of a poorly finished application.
Good practice: make the main control stretch (often the table, so the user sees more rows), make action buttons move so they remain visible, keep small labels fixed.
3. Naming and tab order
Name the controls explicitly, with a prefix convention: SAI_NomClient, BTN_Valider, TABLE_Articles. It is by this name that you will handle them in WLangage; a meaningful name makes the code readable and searchable.
Finally, mind the TAB ORDER: the order in which the Tab key moves from one control to the next. In management apps, keyboard input is the norm — an order that follows the logical input sequence changes everything for speed and limits errors.
🔎 Concrete example — 🔎 Concrete example — Naming and anchoring controls
Yacine's convention for the “Fiche commande” window:
// Convention de nommage des champs
SAI_NomClient : champ de saisie (préfixe SAI_)
BTN_Valider : bouton (préfixe BTN_)
TABLE_Articles : table de données (préfixe TABLE_)
LIB_Titre : libellé (préfixe LIB_)
// Ancrage (redimensionnement)
TABLE_Articles → étirer (largeur + hauteur)
BTN_Valider → déplacer (bas / droite)
LIB_Titre → rester fixeReading: the name clearly says which control is being handled, and anchoring indicates how the interface reacts to enlargement.
Reflex: name explicitly and make the main control (the table) stretch as soon as the window is created.
Section vocabulary
- Control (WinDev)
- Interface component dropped onto a window: label, input, button, switch, combo box, table, image, tab… Each control has a name and properties.
Simple example: Yacine drops an SAI_NomClient input control onto the order window.
What it is not: drawing everything by hand without using interface components.
Reflex: interface component → a named control.
- Table control
- Major control in management apps: displays several records as rows and columns; can be linked to a file or a query.
Simple example: Yacine displays the order's item lines in a table.
What it is not: displaying each line in a separate input control, without a table.
Reflex: several records → a table.
- Anchoring
- Behavior of a control when the window is resized: stretch, move, stay fixed.
Simple example: Yacine makes TABLE_Articles stretch in width and height.
What it is not: enlarging the window and leaving the controls frozen in an empty corner.
Reflex: resizing → set anchoring.
- Explicit naming
- Giving controls meaningful names (SAI_NomClient) with a prefix per type, because it is by this name that they are handled in WLangage.
Simple example: Yacine renames SAI_Sans_nom1 to SAI_NomClient.
What it is not: leaving generic names that make the code unreadable.
Reflex: a control → an explicit name.
- Tab order
- Order in which the Tab key moves from one control to the next; must follow the logical input order.
Simple example: Yacine sets Tab: Nom → Téléphone → Articles → Valider.
What it is not: a Tab that jumps from name to postal code then back to first name.
Reflex: smooth input → logical tab order.
In practice — In practice — Drawing an input window
- Create a window and drop the necessary CONTROLS from the catalog (labels, input controls, buttons) by drag and drop.
- Rename each control with an EXPLICIT name (prefix convention) — that is how you will handle it in WLangage.
- Take care of the layout: logical input order, alignment, grouping of related information, clear labels.
- Set the ANCHORING of the controls (resize behavior) and check the TAB ORDER for smooth keyboard input.
Step-by-step script — drawing the window like Yacine (4 min)
1) Create a window (e.g. “Fiche commande”) and drop the necessary controls by drag and drop. 2) Rename each control with an explicit prefix (SAI_, BTN_, TABLE_, LIB_). 3) Organize the layout in logical reading and input order. 4) Set anchoring: main control stretched, buttons moved, labels fixed. 5) Check the tab order by entering data from the keyboard.
A window is judged in use: clear names, correct anchoring and a logical Tab order from the first version.
Copy-paste template — Yacine's window checklist
[ ] Controls dropped by drag and drop (input, button, table…)
[ ] Explicit naming with prefixes (SAI_, BTN_, TABLE_, LIB_)
[ ] Layout in logical input order
[ ] Main control anchored to stretch (table)
[ ] Action buttons anchored to move
[ ] Labels anchored fixed so they do not move
[ ] Tab order checked from the keyboardConsultation window
Yacine only puts a large orders table, anchored to stretch, with few input controls.
Add window
Yacine lays out the input controls in a column, in input order, with Valider/Annuler anchored at the bottom.
Tabs
For a complete customer record, Yacine spreads the information across tabs (Identité, Coordonnées, Historique).
Workshop screen
On a workshop workstation, Yacine enlarges the buttons and takes care with spacing for comfortable use.
✓ Best practices
- Name controls explicitly with a prefix convention.
- Set anchoring: stretch the table, move the buttons, fix the labels.
- Check the tab order for smooth keyboard input.
✗ Common pitfalls
- Leaving generic names such as SAI_Sans_nom1.
- Forgetting anchoring: interface squeezed in a corner when enlarged.
- Neglecting the tab order (Tab jumping all over the place).
Key takeaways
- Windows are drawn visually: controls (label, input, button, table, combo box, tab) are dropped onto them.
- Anchoring defines control behavior on resize: stretch, move, stay fixed.
- Name controls explicitly (SAI_NomClient): it is by this name that they are handled in WLangage.
- A logical tab order determines the speed and reliability of keyboard input.
48h challenge — apply it tomorrow
Take an existing window and make it professional like Yacine: rename the controls with explicit prefixes, set anchoring (table stretched, buttons moved, labels fixed) and fix the tab order. Write in one sentence what anchoring changes when the window is enlarged.
- I know how to create a window and drop controls onto it by drag and drop.
- I understand anchoring and use it for an adaptive interface.
- I name my controls explicitly and set the tab order.
Frequently asked questions
What is anchoring and why is it essential?
Anchoring defines how each control reacts when the window is resized: stretch, move or stay fixed. Without it, an enlarged window shows controls frozen in the top left with a large empty space — a very visible flaw. The most useful case: make the main table stretch, because the user really gains visible rows. Action buttons are then moved so they remain accessible, and labels are kept fixed.
Why take care with control naming and tab order?
Explicit naming makes WLangage code readable and maintainable: a control is handled by its name, so “SAI_NomClient” explains itself whereas “SAI_Sans_nom1” means nothing six months later. Tab order determines input speed: in management apps you move through controls from the keyboard, and an inconsistent order wastes time and causes errors. Two details that distinguish a professional application from an amateur one.
What is the purpose of a control's anchoring in a WinDev window?