🎯 Description
Dans le contexte du développement WinDev, il peut être tentant d’utiliser la surcharge de procédures pour créer plusieurs versions de GetModele
(par exemple, une prenant un identifiant numérique, une autre une clé texte). Cependant, cette approche pose des problèmes graves lorsque des appels dynamiques ou inter-modules sont impliqués.
❌ Problème rencontré :
La surcharge de
La surcharge de
GetModele fonctionne en apparence lorsque les appels restent dans le même module, mais fait planter WinDev ou produit un comportement incohérent lorsqu’un objet dynamique ou un autre module tente d’y accéder.
🧪 Exemple problématique
PROCÉDURE GetModele(LOCAL nRefUnite est un entier) : MUnite
PROCÉDURE GetModele(LOCAL sCleConstant est une chaîne) : MUniteCes deux procédures surchargées partagent le même nom. Cela fonctionne localement, mais si un appel est effectué depuis un autre module ou via un objet dynamique, la résolution de méthode échoue, parfois sans message d’erreur.
🚑 Solution
✅ Renommer les procédures pour leur donner un nom unique et explicite, en évitant toute surcharge.
✔️ Exemple corrigé
PROCÉDURE GetModele(LOCAL nRefUnite est un entier) : MUnite
PROCÉDURE GetModeleSelonConstant(LOCAL sCleConstant est une chaîne) : MUniteEn renommant la deuxième procédure, on élimine l’ambiguïté, et les appels dynamiques ou inter-modules fonctionnent correctement sans planter.
📌 Recommandations
- Éviter la surcharge de noms de procédures dans WinDev, même si elle semble fonctionner localement.
- Donner des noms explicites aux procédures pour mieux refléter leur rôle (
GetModeleSelonRef,GetModeleParCle, etc.). - Tester systématiquement les appels inter-modules ou dynamiques dès qu’une procédure est modifiée.
🧠 À retenir
🔄 Surcharge dans WinDev : Éviter dès qu’on travaille avec des objets dynamiques ou des modules séparés.
Préférer une procédure = un nom unique = un comportement clair et débogable.
Préférer une procédure = un nom unique = un comportement clair et débogable.