FAQ n°8865, publiée le 18/02/2014, mise à jour le 03/03/2017
WINDEV, WEBDEV, WINDEV MOBILE
Que faire si l'utilisation d'un module externe (ActiveX, Assemblage .Net, objet OLE Automation) impacte des fonctionnalités d'une application WINDEV ?
Lorsqu'une application intègre un module externe comme un Assemblage .Net, un champ ActiveX, un objet OLE Automation, il peut être observé des effets sur les fonctionnalités de l'application : 
  • authentification via OAuth2 affiche une fenêtre vide,
  • effet d'affichage lors de l'ajout d'un champ ActiveX,
  • perte de la possibilité d'effectuer un drag & drop après l'ajout d'un assemblage .net,
  • déclenchement du mécanisme de sécurité du WLangage en mentionnant le module OLEAUT32.DLL de Windows ...
Ces effets proviennent d'un conflit dans l'ordre d'initialisation de fonctionnalités de Windows qui sont utilisées à la fois par le Framework de l'application WINDEV, et par le module externe (Assemblage DotNet, ActiveX, …). 

Lorsque le cas se produit, voici le code à ajouter dans l'initialisation du projet :

SI ChargeDLL("OLE32")=0 ALORS
Erreur("Echec de chargement de OLE32", ErreurInfo())
SINON
SELON API("OLE32","CoInitializeEx",Null,2)
CAS 0//OK
CAS 1
API("OLE32","CoUninitialize")
SI API("OLE32","CoInitializeEx",Null,2)<>0 ALORS
Erreur("Echec de CoInitializeEx", ErreurInfo())
FIN
AUTRE CAS
Erreur("Echec de CoInitializeEx", ErreurInfo())
FIN
FIN


Remarques importantes sur ce code :
  • suivant le cas il ne s'applique qu'à l'exécutable, et n'a pas d'effet en mode test "Go",
  • dans le cas d'un conflit avec un assemblage ou objet Automation, le code doit précéder la déclaration de l'objet. Si la déclaration est placée dans une collection de procédures, ou la déclaration d'une classe, il faut que le code soit dans la déclaration de la collection, ou de la classe. En effet le code du projet est exécuté après le code de déclaration des classes, et des collections de procédures.
  • la documentation de la fonction Windows utilisée est disponible sur le site de l'éditeur.