7 min de lecture

Convertir du WLangage en C# : méthode, équivalences et pièges

Le WLangage 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.

WLangage C# .NET Conversion

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. Notre guide complet : migrer depuis WinDev.

Équivalences de base WLangage → C#

WLangageC#
chaîne, entier, réel, booléenstring, int, double, bool
x est une chaîne = "abc"var x = "abc";
POUR i = 1 À 10 ... FINfor (int i = 1; i <= 10; i++) { }
TANTQUE / BOUCLEwhile / do-while
SELON ... CASswitch ... case
tableau de chaînesList<string>
structureclass / record
procédure / fonctionmé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.

Un projet de conversion WLangage → C# ? Audit gratuit et estimation — contact@wxit.fr.

← Retour aux guides