Intégrateur d'ActiveX

On retrouve sous cette fenêtre la liste des constantes, événements, propriétés et méthodes de l’ActiveX.

Cliquez sur « Suivant ».

• Saisissez les caractéristiques de l’OGB (nom, désignation, préfixe).
• Précisez le nom de la DLL, ainsi que son chemin dans lequel elle sera générée (Répertoire de destination du fichier .DLL généré). Le chemin peut être la racine d’Adélia, soit un autre chemin pourvu que celui-ci soit connu dans le PATH système.
• Cochez le(s) environnement(s) dans lesquels sera créé l’OGB.
• Pour chaque environnement, vous pouvez préciser un répertoire qui servira lors de la création de l’OGB.
  • Par défaut, ce répertoire est le même que le répertoire de génération de la DLL.
  • Si vous mettez un autre chemin, 2 conditions sont à respecter :
    • Cet autre chemin doit être dans le PATH système
    • La DLL généré doit être copiée dans cet autre chemin.

Objet Adélia correspondant à l’OCX :

 - Parmi les OGB :

Utiliser l’OCX sur les autres postes développeur et sur les postes utilisateur :

Sur les postes de développement, comme sur les postes utilisateurs, mettez : la DLL de l’ActiveX + la (les) DLL(s) issue(s) de l’intégration.

• 1 DLL est générée en version ≤ V10
• 3 DLLs sont générées depuis la V11 :
  • « <ActiveX >u.dll » pour la version Unicode
  • « <ActiveX >a.dll » pour la version Ansi
  • « <ActiveX>.dll » pour la version mixte.

Puis, enregistrez la DLL de l’OCX (uniquement) par la commande regsvr32, exécutée depuis une fenêtre de commandes DOS démarrée en tant qu'administrateur.

Enfin, il faut que les chemins dans lesquels se trouvent ces DLL soient connus dans le PATH système du poste.

En cas d’erreur (message ou sens interdit devant l’OCX dans les options du maquetteur) :

Regardez le rapport (bouton « Rapport ») de l'intégrateur d'ActiveX.

Reportez-vous à l’aide en ligne : « ActiveX : erreurs lors de la compilation des fichiers sources ».

En cas d’erreur à l’exécution :

Assurez-vous que les 3 DLL « <ActiveX>.dll » « < ActiveX >u.dll » et « < ActiveX >a.dll » résultant de l’intégration de l’ActiveX ont bien été toutes les 3 déployées.

Si le compilateur utilisé est C++ 2005 ou C++ 2008 (production de .manifest) :

• Les programmes Visual sont générés en C. Donc, le compilateur produit des .manifest qui font référence au runtime C.
• La DLL générée par l’intégrateur d’OCX est en C++. Donc, lors de l’utilisation de cette DLL, le système a besoin du runtime C++.
• Du coup, lorsque vous exécutez des programmes Visual qui utilisent l’OCX, lors du chargement de la dll de l’OCX (produit via l’intégrateur Adélia), le système a besoin du runtime C++, mais celui-ci n’est pas référencé dans le .exe.manifest du point d’entrée.
• Pour que le .exe.manifest du point d'entrée de l’application Visual reconnaisse le runtime C++ :
  
  • Copiez n’importe quel fichier .exe.manifest qui se trouve sous la racine d’Adélia. Ces .manifest font référence aux runtimes C et C++.
  • Remplacez le fichier .exe.manifest lié au point d'entrée (.exe) de l’application Visual par celui que vous venez de copier, et donnez-lui le même nom que celui du programme.
  • Par exemple pour un programme qui s’appelle MONPGM :
    • Copiez AdelEnv.exe.manifest, qui se trouve sous la racine d’Adélia.
    • Supprimez MON_PGM.exe.manifest, qui se trouve parmi les objets générés.
    • Collez AdelEnv.exe.manifest dans le répertoire des objets générés.
    • Renommez AdelEnv.exe.manifest que vous venez de coller en MONPGM.exe.manifest.
• Pour que lors des générations futures de programmes Visual, ce soit un manifest Adélia (qui fait référence aux runtimes C et C++) qui soit repris (et non celui du compilateur) :
  • Copiez un .manifest, qui se trouve sous la racine d’Adélia, en ansi.manifest dans la racine d’Adélia sur les serveurs de compilation.