Le WLangage contient de nombreux types très évolués (types avancés, types de variables, ...). Il peut arriver que le nom d'un type WLangage, soit identique à celui d'un autre type inclus par un élément ajouté au projet (assemblage, type structuré, webservices...). Dans ce cas, la déclaration ou l'instanciation d'une variable provoque une erreur de compilation.

 

Par exemple en version 24(*) de WINDEV le code suivant :

// projet ayant l'assemblage Microsoft.Exchange.WebServices importé
oServiceExchange:Url = new Uri("https://msmail.montest.com/ews/Exchange.asmx")

 

Déclenche l'erreur de compilation suivante :

Utilisation ambiguë du type 'Uri'.

Plusieurs types du projet (types avancés du WLangage, classes d'assemblages .NET importés ou types structurés de Webservice) portent ce nom. Utiliser le nom complet du type à utiliser.

 

Une syntaxe dédiée est disponible dans pareil cas, afin de lever l'ambiguité et permettre la compilation. Il suffit de préfixer le type, de son emplacement. Par exemple le code :

oServiceExchange:Url = new Uri("https://msmail.montest.com/ews/Exchange.asmx")

devient :

oServiceExchange:Url = new System.Uri("https://msmail.montest.com/ews/Exchange.asmx")

 

Rappelons que l'apostrophe (quote) permet d'encadrer un nom, si celui-ci contient des espaces. On peut donc également écrire :

oServiceExchange:Url = new 'Systeme.Uri'("https://msmail.montest.com/ews/Exchange.asmx")

 

Rappelons pour le cas inverse, lorsqu'un type ou une fonction du WLangage est surchargé, on peut forcer l'utilisation du type ou de la fonction WLangage en le préfixant de ".WL".

Par exemple : MaVariable est un WL.<type>.

 

(*) conflit possible uniquement à partir de la version 24, car elle intègre un type Uri et un jeu de fonctions Uri* qui n'existait pas en WLangage dans les versions antérieures.

 

 

< Retour

2 commentaires

Fracassi Didier
29/09/2021 - 16:15 - Répondre
Votre solution ne vaut rien, ce n'est pas du tout une solution. Dans une dll de base de mon projet qui est en c# je dois inclure un interop office qui déclare une interface "Email". Vu qu'il existe la variable globale Email dans windev cela crée un conflit, le problème c'est que la variable Email est utilisé dans différents composants du même projet. Votre solution consisterait à devoir modifier dans tous les composants tous les appels à la variable globale Email windev ? Etant donné que j'ai des dizaines de référence ça me prendrait plusieurs jours à tous les rechercher puis faire valider les modifs par le service de test. Exclure un namespace serait une solution viable, là ce que vous dites ne sert qu'au peron qui a un projet miniscule qu'il vient de créer ... vous savez que des entreprises utilisent votre agl ?!

Dimitri SIGISCAR
08/09/2022 - 15:27 - Répondre
+1

Publier un commentaire : 
Votre adresse email ne sera pas publiée