Discussion :

[vanitom]

Bonjour à vous tous,

Je viens vous voir car j'ai essayé de faire un truc qui est assez compliqué mais j'arrive au bout de mes moyens. Bon je m'explique.
Je veux pour créer une classe quelquonque dont le nom est inconnu au moment de la compilation, et dont le nom est contenu dans une chaine de caractères.
Pour etre plus précis, j'ai une classe CDpPompe qui est général ( dans son fonctionnement ) contenu dans une DLL DPPOMPE.DLL, et une autre class CDpPompeDepot qui est particulière au dépot contenu dans une autre DLL DEPOT.DLL. Mon souhait est de créer un objet CDpPompeDepot si cet objet existe et dans le cas contraire créer un objet de la classe CDpPompe.

J'ai cherché dans l'aide et j'ai trouvé la méthode "CreateObject" contenu dans la classe"CRuntimeClass". Voici un exemple pour commencer, me permettant de vérifier que la classe 'CDpPompe' était correctement configurer grâce à "DECLARE_DYNCREATE ( CDpPompe )" et "IMPLEMENT_DYNCREATE (CDpPompe, CObject)".

Code :

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

1
2
    CRuntimeClass* pRuntimeClass = RUNTIME_CLASS( CDpPompe );
    CObject* pObject = pRuntimeClass->CreateObject();

Ca, ca marche correctement. Mais ce ne rentre pas dans mes souhait. Le nom de la classe est rentré en dur dans le code.

Cependant il existe un autre contructeur de "CreateObject" qui est :

Code :

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

1
2
3
		static CObject* PASCAL CreateObject(
   				LPCSTR lpszClassName 
		);

Donc mon test est :

Code :

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

1
2
    CRuntimeClass* pRuntimeClass = this->GetRuntimeClass ( );
		CObject* pObject = pClass->CreateObject("CDpPompe");

Et le resultat est accablant, pObject = 0x00000000 à quelques 0 près.

J'ai peut être une idée. Le 'this' correspond à une la classe actuelle qui est un objet de la classe CWinApp. Peut être faudrait-il utilisé quelques chose à la place du 'this'.

Donc j'ai tout vérifier, CDpPompe hérite bien de CObject. Les macros DECLARE_DYNCREATE, et IMPLEMENT_DYNCREATE sont correctement écrit.

Vanitom

[Rely]

Tu peux gérer cela COM précisement avec les interfaces COM. Tu crées l'interface tu l'implémentes au autant de fois que tu veux dans tes DLL et à l'aide des mécanisme de COM tu peux instancier à l'aide du CLSID qui est une chaine de caractère et ....
Si tu ça t'intéresse on verra pour la suite.

[mat.M]

Je veux pour créer une classe quelquonque dont le nom est inconnu au moment de la compilation, et dont le nom est contenu dans une chaine de caractères.

En C++ de toute façon le nom de classe disparaîtra... Une classe qui s'appelle class1 par exemple , le nom d'identifiant ne représente plus rien une fois le programme compilé.

Je ne comprends pas pourquoi tu veux un nom de classe inconnu.
Un identifiant qui ....ne peut pas être identifié c'est impossible en programmation.

Ca, ca marche correctement. Mais ce ne rentre pas dans mes souhait. Le nom de la classe est rentré en dur dans le code.

C'est normal que le nom de classe soit rentré en dur dans le code !!
Comment veux tu que le compilateur s'en sorte lors de la compilation ?

Je ne comprends pas ce que tu veux faire et la finalité de la chose.

Si tu veux allouer des éléments de manière dynamiquement il y a new pour cela .
Mais c'est toujours l'allocation d'UN TYPE PARTICULIER ( int , double , classe particulière etc....)
Sinon il y a le type COM _variant

[mtopoloff]

Rely a absolument raison, sous windows il faut passer par COM. Si non tu aussi toute l'architecture SOAP mais bon, comme tu parles de DLL... COM sera tres bien. Je pense que Rely devrait expliquer comment resoudre ton probleme, si non cherche dans le forum et sur google..

[mat.M]

Rely a absolument raison, sous windows il faut passer par COM

oui mais sous COM le problème demeurera radicalement IDENTIQUE ;
Il sera contraint de déclarer une classe ; le fait d'adresser des méthodes inconnues ne changent rien ( avec IUnknow )
Et il n'a tjs pas répondu et on ne sait pas ce qu'il veut faire précisément;
du moins je ne vois pas l'intérêt d'aller chercher midi à 14 heures

[Rely]

Rely a absolument raison, sous windows il faut passer par COM

oui mais sous COM le problème demeurera radicalement IDENTIQUE ;
Il sera contraint de déclarer une classe ; le fait d'adresser des méthodes inconnues ne changent rien ( avec IUnknow )

Ben non Mat.M; Si on définit un interface COM qu'on implémente dans une DLL cette on peut créer des instances de la classe à la l'aide du Progid qui est une chaine de caractère enregistré dans la base des registres et on peut Obtenir un pointeur sur l'interface qu'on a définit donc on aura accès aux methodes et aux propriétés de l'interface. En tout cas moi je l'ai fait plusieurs fois!

[vanitom]

Merci les gars mais le problème est résolu. Je suis allé très loin dans le code de visual mais maintenant c'est bon.

Je pense que quelques explications sont souhaitable.

Alors

Je suis parti sur le principe d'utiliser "CreateObject" Donc j'ai foncé tête baissée. En fait pour utiliser c'est fonction il faut que la classe appartienne à une librairie d'extension MFC. Pour cela il faut initialiser la DLL avec quelques particularités. Il faut insérer le code suivant une seule fois dans la DLL

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
externe "C" int APIENTRY
DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
	UNREFERENCED_PARAMETER(lpReserved);
	if ( dwReason == DLL_PROCESS_ATTACH )
	{
		if ( !AfxInitExtensionModule(Class1, hInstance) )
			return 0;
 
		new CDynLinkLibrary (Class1);
	}
	else if ( dwReason == DLL_PROCESS_DETACH )
	{
		AfxTermExtensionModule ( Class1 );
	}
}

Cette fonction permet d'ajouter la DLL dans la liste des DLLs d'extension.
Quand on fait 'CreateObject("Class1")', Visual recherche dans cette liste toutes les DLLs d'extension puis compare dans chacune d'elle le nom de toutes les classes avec le nom passé en paramètre.
Il faut charger la DLL avant d'appeller la methode 'CreateObject("Class1")'. Cependant, une DLL n'est chargé que quand on créer au moins une classe d'une DLL.
Il fallait donc chercher un moyen de charger la DLL manuellement avant de lancer la méthode 'CreateObject("Class1")'.
Il suffit d'utilise la fontion AfxLoadLibrary ( "DLL_NAME.DLL" ).

Et le tour est joué.

[farscape]

salut ,
je suppose que tu utilises vc .net et pas vc6.0 non ?

[mat.M]

Ben non Mat.M; Si on définit un interface COM qu'on implémente dans une DLL cette on peut créer des instances de la classe à la l'aide du Progid qui est une chaine de caractère enregistré dans la base des registres et on peut Obtenir un pointeur sur l'interface qu'on a définit donc on aura accès aux methodes et aux propriétés de l'interface. En tout cas moi je l'ai fait plusieurs fois!

tu as totalement lu de travers ce que j'ai écrit et rien compris à ce que j'ai écris!!!
Oui on peut faire ceci cela dans une interface COM mais on est OBLIGE d'identifier une classe même dans un composant COM.
D'ailleurs le problème vient essentiellement de la personne à l'origine de ce post qui n'a pas répondu à mes questions

[vanitom]

Effectivement je code sous Visual .Net . Je ne pensais que c'était aussi différent entre Visual 6.0 et la version .Net