Erreur lors d'une modification d'interface ActiveX

Bonjour,

Je rencontre le problème suivant: je dispose d'un interface activeX, utilisé dans un projet C++ builder (le tout via l'import du tlb correspondant). L'interface été récemment mis à jour avec l'ajout de nouvelles méthodes à une des classes, et depuis il m'est impossible d'acceder à la classe modifiée. J'ai à chaque fois le message suivant :

Classe non enregistrée, ClassID: "GUID"

Et si je commente les modifications de l'interface, je n'ai plus d'erreurs ...

Si quelqu'un pouvait me donner quelque information, cela m'aiderait grandement ....
Merci beaucoup

L'Import TLB a été fait sur le même poste que celui que tu utilises ?
L'ActiveX installé est-il de la bonne version ?
un Regsvr32 a bien été fait ?

En général, on évite de modifier une interface déployée, on ajoute une autre interface qui propose les nouvelles méthodes, l'implementation de la 1ère interface fourni aussi celle de la nouvelle, l'objet IUnknown peut être caster d'une interface à une autre !

Merci pour ta réponse rapide.

Je vais regarder en ajoutant une nouvelle interface, cela devrait effectivement marcher.
Pour la version de l'ActiveX installé, je suis sûr de mon coup vu qu'il s'agit d'un contrôle graphique, je vois bien si il est modifié. Et l'import du tlb est bien fait sur le même poste.

Ce qui me surprend le plus, c'est vraiment que la moindre modification d'une interface, entraine une erreur "classe non enregistrée" ...

Une précision supplémentaire: même quand je change le GUID de l'interface modifiée, l'erreur me renvoie l'ancien GUID ...

J'ai fait comme tu m'as dit et effectivement ça marche bien :

J'ai créé dans l'activeX un interface IToto2 héritant de IToto, comme ça IToto ne bouge pas et on a les nouvelles méthodes dans IToto2.

Par contre comment expliquer que la modification de IToto crée ensuite et systematiquement une erreur ?

Merci

Je n'ai pas encore fait d'interface avec C++Builder !
En Delphi, c'est une chose courante durant le développement, on ajoute méthodes, énumérations et propriétés, cela ne pose pas de problème !
Je n'ai fait qu'un seul Control ActiveX pour l'intégrer dans Navision
Je n'ai pas eu ce genre de problème !
J'avais modifié un composant d'un ami développeur Navision, il n'avait personne sous la main pour lui modifier le compo Delphi, je lui ai ajouté les méthodes qu'il avait besoin pour améliorer l'ergonomie et la maitrise sur le Control ActiveX
Moi, pour tester, j'utilisais un petit programme Delphi, je pense n'avoir eu aucun soucis car je lui ai vite fait bien fait ça en une petite matinée ! Si j'avais eu des soucis du genre, ça m'aurait gavé !

C'est comme si un GUID changeait entre l'ancienne et la nouvelle interface !

Je vois un cas où cela pourrait produire une telle erreur :
- Création du Control ActiveX
- Design des Interfaces (A, B, C)
- Implementation
- Installation (RegSrv32)
- Ajout de nouvelle Interface (D et E)
- Ajout de fonction dans A qui prend en paramètre une interface D

Si tu ne refais pas un RegSvr32, tu as un risque qu'il manque des GUID dans la Base de Registre de D et E
Selon l'utilisation, cela peut-être bloquant ou pas

Avec IToto2, tu n'as pas de problème car tu as son type, tu as GUID dans le TLB, c'est Dephi qui bosse ! Ce n'est qu'un transtypage, cela utilise la méthode QueryInterface qui fait son boulot et tu renvoie l'interface demandée, je ne pense pas qu'il soit nécessaire que celle-ci soit enregistrée dans la BDR ! A Vérifier
C'est peut-être même ce que tu as fait à l'instant avec IToto2 !

As-tu relancé RegSvr32 après avoir ajouter IToto2 ?

Citation:

---

Une précision supplémentaire: même quand je change le GUID de l'interface modifiée, l'erreur me renvoie l'ancien GUID ...

---

As-tu relancé RegSvr32 après avoir changer le GUID ?
n'hésite pas faire RegSvr32 -u pour désintaller, puis un autre RegSvr32, pour installer de nouveau

Parcontre, si tu as besoin d'une interface D comme paramètre d'une fonction de A, le programme appelant doit faire un CreateOleObject (ou Create d'une CoClass) de D et là le GUID doit être présent dans la BDR pour savoir quoi faire (quelle DLL contient cet objet)

Merci pour ces infos.

Je ne fais pas de RegSvr32.
Mon workflow précis est :

- Création de la dll (c#) et du tlb
- Enregistrement de la dll via Regasm dll /codebase .
- import du tlb et création d'un client c++ builder

La chose qui me paraît mysterieuse, c'est d'où sort le GUID du message d'erreur ? du tlb ou d'un enregistrement ?

C'est une DLL contenant un Assembly.net compatible COM !
Cela change tout !

Je ne sais pas comment fonctionne le C# !
Tout ce que je sais c'est que l'interopérabilité Win32 vs .NET, c'est souvent pénible, j'ai du faire des ActiveX Win32 (en Delphi), il faut faire bien attention à ce que l'on fait pour rester en safecall pour que cela fonctionne correctement !

Bon je vais clore le sujet, le problème en lui même étant résolu. J'ouvrirai un autre topic plus précis si je rencontre de nouveau un pb similaire.

Merci pour tes réponses.