Discussion :

[bossun]

Salut,

J'ai une dll C++ que je n'arrive pas à enregistrer dans la base de registre. J'utilise cette dll depuis plusieurs programmes et je dois toujours leur indiquer le chemin absolu.


Je sais qu'il faut ajouter quelques part la fonction d'enregistrement DLLRegisterServer mais je ne vois pas comment faire ni où l'ajouter.

J'avoue que le C++, j'en ai jamais fait.

Merci pour votre aide

[Médinoc]

On n'enregistre une DLL avec DllRegisterServer() que si la DLL en question est un composant COM.
Une DLL ordinaire ne s'enregistre pas (sauf les DLLs partagées, pour les programmes d'installation, mais je crois que ça ne change rien au coup du chemin). Par contre, tu peux ajouter le répertoire la contenant à la variable d'environnement PATH.

[bossun]

Idéalement il faudrait que ça soit une DLL COM mais je ne vois pas comment créer en C++. Y a-t-il quelque chose à ajouter dans le code ou dans les options de compilations pour lui dire que c'est une dll Com?

Merci d'avance

[fregolo52]

En effet il y a des choses a faire.
Quand on crée un projet ATL COM avec Visual, il ajoute un fichier idl où se trouve le CLID (uuid) de ton objet.

Et d'autre petites choses que je ne pourrais pas expliquer, je n'ai pas fait de CORBA et très peu de COM.

[Médinoc]

Une DLL COM ne se fait pas à la légère: C'est tout un paradigme orienté objet qui entre en jeu...

Pour ça, tu aurais plus vite fait d'écrire ta DLL en .Net et la régler en "COM-Visible"...

[buggen25]

Salut
Quand on crée des DLL avec un projet ATL COM, il généré des fichiers .c et des fichier .h , il faut ajouter ces fichier au projet avec des "include":
Comme je me souviens pas tres bien des fichiers a inclure dans le projet
primo, inclure tous les fichier
secondo, exclure tout les fichiers qui ne sont pas utilisé
Ses fichiers en question contiennent les GUID( Globally Unique IDentifier : c'est un identifiant unique :Adress physique en combinaison avec la date -> UNIQUE des COM DLL générés, et plein d'autre chose.
Dès la génération du projet ATL COM le composant est enregistré dans la base de registre, si on CHANGE le repertoire de la DLL généré le composant n'est plus reconnue par le systeme.
Donc il faut enregistrer le composant soit avec DllRegisterServer(), ou bien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
"Windows R"
cmd
cd chemin/vers/repertoire DLL
RegSvr32 laDll.dll

Ce qui est pareil

[nicroman]

Faut pas exagérer non plus....

DllRegisterServer est LA fonction appelée par regsvr32.exe (et les installeurs)... Mais ca n'amenera rien de plus.

regsvr32.exe va juste appeler deux points d'entrées de la DLL... qu'il suffit de déclarer comme tels !
Nul besoin que la DLL soit un COM-Server !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
extern "C" {
__declspec(dllexport) STDAPI DllRegisterServer(void)
{
....
}
__declspec(dllexport) STDAPI DllUnregisterServer(void)
{
....
}
 
}

Apres... pour faire du COM il "suffit" de rajouter un DllGetClassObject() et un DllCanUnloadNow()

Beaucoup de programmeurs pensent que COM est très compliqué, mais il suffit d'implémenter ces 4 fonctions de base, pour avoir un serveur COM parfaitement fonctionnel !

[Médinoc]

@nicroman: Tu oublies que faire ceci ne "trouvera" la DLL que si tu fais un CoCreateInstance() ou CoGetClassObject(), donc ce n'est pas ça qui permettra à la DLL d'être systématiquement trouvée au chargement du programme.

Et ensuite, il faut que ce que retourne DllGetClassObject() respecte les règles COM.

[buggen25]

medinoc, t'a raison il faut appeler CocreateInstance() pour créer une instance d'un objet com. car on peut pas instancier une classe purement abstraite ce qui est le principe de toute la technologie com. sans oublier CoInitialize.
@nicroman: ensuite il faut créer des interfaces, appeler les interfaces, utiliser les fonction de cette interface etc.. c'est pas aussi simple.
Concernant ton code. c'est tres compliqué
De plus Regsvr32 ne sert pas qu'a enregistrer les objets COM, il existe aussi les Fichier .ocx a savoir les DLL ActiveX
ps: Tout les programmes sont difficile a développer.

[Médinoc]

De plus Regsvr32 ne sert pas qu'a enregistrer les objets COM, il existe aussi les Fichier .ocx a savoir les DLL ActiveX
ps: Tout les programmes sont difficile a développer.

Pour moi, ça rentre dans la catégorie "composants COM".

[buggen25]

Slt.
Tout a fait d'accord. Disons qu'un contrôle active X est plutôt ostensible, et plus orienté contrôles comme le contrôle active X Windows Media Player, qu'on peut utiliser directement sur une page WORD par exemple, ou sur une boite de dialogue MFC. Il possède aussi une fenêtre de paramétrage

En revanche d3d9.dll on ne fait que appeler une des ses interfaces internes IDirect3DDevice9 ensuite on appelle les fonctions de cette interface

Cependant, nous pourrions utiliser des objets com pour afficher des fenêtres.

Tout réside dans la manière avec laquelle le composant a été conçu(Dll,OCX), et dans quel but il sera utilisé.