Discussion :

[Kevgeii]

Bonjour,

Je voudrais savoir comment connaitre les interfaces disponibles dans des fichiers de types DLL ou EXE, je parle des classe qui sont importer quand on utilise le menu automation du classWizard de VC++6, les classes dérivées de COleDispatchDriver.

Merci,

[mat.M]

je ne sais pas si cela va répondre à ta question mais apparemment il faut passer évidemment par QueryInterface et utiliser IDataObject avec les méthodes EnumDAdvise et EnumFormatEtc

cf MSDN

Getting a Pointer to an Object
Because COM does not have a strict class model, there are several ways to instantiate or to get a pointer to an interface on an object. There are, in fact, four methods through which a client obtains its first interface pointer to a given object:

Call a COM Library API function that creates an object of a pre-determined type — that is, the function will only return a pointer to one specific interface for a specific object class.
Call a COM Library API function that can create an object based on a class identifier (CLSID) and that returns any type of interface pointer requested.
Call a method of some interface that creates another object (or connects to an existing one) and returns an interface pointer on that separate object.
Implement an object with an interface through which other objects pass their interface pointer to the client directly.
For information on getting pointers to other interfaces on an object once you have the first one, see QueryInterface: Navigating in an Object.

There are numerous COM functions that return pointers to specific interface implementations, such as CoGetMalloc, which retrieves a pointer to the standard COM memory allocator. Most of these are helper functions, which retrieve a pointer to an COM implementation of an interface on an object, as does CoGetMalloc. Most of these functions are described in the specific area they are related to, such as storage or data transfer.

There are several functions that, given a CLSID, a client can call to create an object instance and get a pointer to it. All of these functions are based on the function CoGetClassObject, which creates a class object and supplies a pointer to an interface that allows you to create instances of that class. While there must be information that says which system the server resides on, there is no need for that information to be contained in the client. The client needs to know only the CLSID, and never the absolute path of the server code. For more information, see Creating an Object through a Class Object.

Among the many interface methods that return a pointer to a separate object are several that create and return a pointer to an enumerator object, which allows you to determine how many items of a given type an object maintains. COM defines interfaces for enumerating a wide variety of items, such as strings, several structures important in various COM technologies, monikers, and IUnknown interface pointers. The typical way to create an enumerator instance and get a pointer to its interface is to call a method from another interface. For example, the IDataObject interface defines two methods, EnumDAdvise and EnumFormatEtc, that return pointers to interfaces on two different enumeration objects. There are many other examples in COM of methods that return pointers to objects, such as the OLE Compound Document interface IOleObject::GetClientSite, which, when called on the embedded or linked object, returns a pointer to the container object's implementation of IOleClientSite.

The fourth way to get a pointer to an object is used when two objects, such as an OLE Compound Document container and server, need bi-directional communication. Each implements an object containing an interface method to which other objects can pass interface pointers. In the case of containers and servers, each object then passes its pointer to the other object. The implementing object, which is also the client of the created object, can then call the method and get the pointer that was passed.

[Aurelien.Regat-Barrel]

Le probleme c'est que le QueryInterface il faut le faire sur un objet. Or si j'ai bien compris il ne l'a pas l'objet, et veut savoir les interface COM exportées par un composant sans installer ce dernier. Je ne crois pas que ce soit possible, de manière fiable en tous cas.
Il faudrait installer le composant, chercher dans la BDR (HKCR\CLSID) à la recherche de la dll / exe afin d'avoir le CLSID / ProgID à utiliser puis désinstaller le composant... Ensuite c'est demander IDispatch et interroger le composant, super lourd à faire...
Sinon sans installer le composant : hooker ses imports de fonctions relatives à la base de registre et détecter les clés crées lors de l'appel manuel de DllRegisterServer... Mais a quoi bon car pour l'interroger il faudra l'installer de toutes façons.

[mat.M]

je sais bien Aurélien j'ai compris sa question mais avec les méthodes que j'ai suggérées cela doit être faisable.
Sinon lire la base de registres comme tu dis

[Aurelien.Regat-Barrel]

je sais bien Aurélien j'ai compris sa question mais avec les méthodes que j'ai suggérées cela doit être faisable.

Le problème est : sur quel objet fais-tu le QueryInterface ?

[Kevgeii]

Merci pour les réponses.

Mais je voudrais faire la même chose que le classWizard de C++.
Ce dernier, juste en séléctionnant un fichier dll ou exe est capable de donner les interfaces disponibles.

Mon probleme et que je dois utiliser les communications OLE/COM avec un soft. Ce dernier possède une cinquante de fichier dll ou exe et je voudrais faire un listing de toutes les interfaces diponibles pour chaque fichier sans me les faire un par un.

[mat.M]

Ce dernier, juste en séléctionnant un fichier dll ou exe est capable de donner les interfaces disponibles.

c'est pas trop possible si tu ne connais pas un minimum du composant cf base de registres )
Essayer avec les pistes que j'ai données plus haut


Les objets COM il ya 4 méthodes principales d'Iunknow et point à la ligne.
Par contre pour une dll classique il est possible de déterminer les imports/exports.

[Aurelien.Regat-Barrel]

Si le dll/exe/ocx contient un tlb alors c'est possible.
Tu peux adapter cet exemple
http://www.codeguru.com/Cpp/COM-Tech/activex/misc/article.php/c2569/
en te servant de LoadTypeLib au lieu de LoadRegTypeLib pour charger directement depuis un ocx/dll/exe...
http://msdn.microsoft.com/library/en-us/automat/htm/chap9_1axu.asp
Attention, ça marche que si le composant dispose d'un tlb...

[Kevgeii]

Merci,

C'est quoi un tlb?

[Aurelien.Regat-Barrel]

C'est les infos concernant le composant, son sommaire en quelque sorte. Au lieu d'interroger l'objet sur tout ce qu'il contient, tu as l'équivalent sous forme de fichier type library (tlb).
C'est grâce à ça que bcp d'outils savent utiliser des composants sans les charger (directive #import sous VC++, vérification des paramètres lors de la compilation en VB, ...)