// guide technique
Convertir du WLangage en C# : méthode, équivalences et pièges
Le WLangage est verbeux mais structurellement simple : il se traduit très bien en C#. Le vrai défi n'est pas la syntaxe — c'est le contexte implicite (HFSQL, variables globales, liaisons IHM) que WinDev gère pour vous. Voici comment aborder la conversion proprement.
Prérequis : exporter le code en format texte
Avant toute conversion, enregistrez vos projets en format texte (option disponible dans les versions récentes pour la compatibilité Git). Vous obtenez le code WLangage, la description des fenêtres et des champs en fichiers lisibles — la matière première idéale pour une conversion assistée par IA, et une sauvegarde pérenne de votre patrimoine. Notre guide complet : migrer depuis WinDev.
Équivalences de base WLangage → C#
| WLangage | C# |
|---|---|
| chaîne, entier, réel, booléen | string, int, double, bool |
| x est une chaîne = "abc" | var x = "abc"; |
| POUR i = 1 À 10 ... FIN | for (int i = 1; i <= 10; i++) { } |
| TANTQUE / BOUCLE | while / do-while |
| SELON ... CAS | switch ... case |
| tableau de chaînes | List<string> |
| structure | class / record |
| procédure / fonction | méthode (void / type retour) |
| ChaîneConstruit(...) | string.Format / interpolation $"..." |
| DateSys(), MaintenantVersChaîne() | DateTime.Now / .ToString(...) |
Le morceau sérieux : l'accès aux données
L'idiome WLangage par excellence — le parcours de fichier HFSQL — se traduit naturellement en LINQ avec Entity Framework, ou en SQL paramétré avec Dapper :
POUR TOUT Commande OÙ DateCmd >= DateDébut ET Statut = "Validée" Total += Commande.MontantHT FIN
var total = db.Commandes
.Where(c =>
c.DateCmd >= dateDebut
&& c.Statut == "Validée")
.Sum(c => c.MontantHT);Les fonctions HLitRecherche, HAjoute, HModifie deviennent des opérations EF/Dapper classiques. La migration de la base elle-même est traitée dans notre guide HFSQL vers SQL Server, PostgreSQL, MySQL ou MariaDB — le code et la base migrent main dans la main.
Les pièges classiques de la conversion
- Le contexte HFSQL implicite — en WLangage, la position courante dans un fichier est un état global (HLitSuivant après HLitRecherche). En C#, tout devient explicite : requêtes, transactions, connexions. C'est plus verbeux mais infiniment plus testable.
- Les variables globales de projet — très courantes dans les projets WX anciens. À transformer en services injectés ou en configuration, sinon le code converti reste intestable.
- Les liaisons fichier-champ — l'EcranVersFichier / FichierVersEcran n'a pas d'équivalent magique : c'est du binding (WPF/Blazor) ou du mapping explicite à reconstruire.
- L'indexation à 1 — les tableaux WLangage commencent à 1, ceux de C# à 0. Le piège le plus sournois des conversions automatiques.
- Chaînes et encodage — ANSI/Unicode, Position(), Milieu() : à mapper soigneusement vers Substring/IndexOf avec les bons décalages.
IA + revue humaine : le bon dosage. Les modèles d'IA actuels traduisent remarquablement bien le WLangage — surtout à partir de l'export texte. Mais ils traduisent ce qui est écrit, pas ce qui est voulu : seule une revue par un développeur qui parle couramment les deux langages garantit que les règles de gestion accumulées sur 15 ans survivent à la traduction. Notre méthode : conversion assistée module par module, tests comparatifs systématiques contre l'application d'origine.
Et les fenêtres ?
L'export texte décrit chaque fenêtre : champs, positions, propriétés, événements. Cette description sert de spécification pour régénérer l'IHM dans la cible (WPF, WinForms, Blazor) — manuellement pour les écrans complexes, assistée par IA pour les écrans CRUD répétitifs qui constituent souvent 80 % d'une application de gestion.
Faites estimer la conversion de votre application
Envoyez-nous les métriques de votre projet (nombre de fenêtres, lignes de code, taille de l'analyse) : nous vous retournons une estimation argumentée, gratuitement.
Demander une estimation