DLL et MainForm je suis perdu !

Bonjour,

Voilà j'ai un petit problème, j'ai fait une application pour un client qui se compose de plusieurs modules (Fiches), je voudrais mettre tout ca en DLL, afin d'avoir que peux de maintenance a faire sur l'ensemble du programme, mais aussi me faciliter la tâche pour les maj !

J'ai donc créer deux projet vierge, l'un est une dll qui posséde une form classique avec un bouton, l'autre est un exe qui posséde également une form classique mais avec trois boutons.

Le 1er bouton de l'exe, fait apparaître la form de la dll(MDIChild), le second bouton ne fait que la faire disparaître et la décharger avec FreeLibrary et le dernier me sert juste a initialiser le caption de la form de la DLL.

Jusque là rien de trés compliqué (surtout quand on a le tut des DLL de LFE sous les yeux, d'ailleurs merci :lol: :lol: ), le problème est que j'aimerais bien faire en sorte qu'a partir du bouton de ma dll je puisse changer une variable quelconque de ma mainform, disons int var=0; au départ et que j'aimerais qu'elle soit à 1.

Déjà est-ce possible et si oui comment ?

Car a chaque fois que je fait Form1->var = 1;, le compilateur me jette, ce qui est évident puisque Form1 n'est pas connu et même si j'inclue le Unit1.h, au moment de faire le link, il me dit "unresolved external "_Form1" ..." !

Cela devient trés énervant a force :evil: :evil:

Si quelqu'un a une idée, elle est la bienvenue.

Rudy.

Il faut passer à ta dll un pointeur sur ta form1 ou à ta variable var.

Ok, mais comment fait tu pour lui passer un pointeur de la Form1, car quand j'essaie, et que j'utilise var qui dépend de Form1, il me met une erreur comme quoi var n'est pas un membre de Form1 !

Merci.

Qu'est-ce que c'est, "Form1" ? La fiche de l'EXE, de la DLL ... ou les deux ?

Effectivement, c'est pas trés claire, la form1 est la form de l'EXE et la form2 celle de la DLL.

Mais je crois avoir trouvé une solution, peux être pas trés "propre", mais faut voir, j'essaie et je vous dit ce qu'il en est !

Salut !

Il doit y avoir au moins deux possibilités utilisant à la base la GetProcAddress de l'API :

- soit pour récupérer l'adresse d'une fonction qui à l'aide d'un paramètre va modifier
la variable
- soit pour récupérer l'adresse de la variable pour la modifier directement

Celà sous entend que ces éléments (fonction et/ou variable) soient déclarés comme exportables dans leur dll
afin qu'un autre module puisse en récupérer l'adresse avec GetProcAddress.

A plus !

Salut,

Alors j'ai pas tout compris, mais le principe est ok, seulement je cherchais a directement modifier les variables sans passer par des fonctions spécifiques ayant chacune cinq paramètres voir plus (c'est le minimum) !

En fait j'ai trouvé une solution, surement pas trés "propre", mais si vous avez mieux ...

Dans mon Unit2.h, j'ai tout simplement mis :

#ifdef dll
TForm1 *res;
#else
TForm *res;
#endif

et dans Unit2.cpp, j'ai :

#ifndef dll
#define dll
#endif

Pourquoi me direz-vous ? Tout simplement parceque La form2 correspond a ma DLL, et que pour accéder a la form1, il faut inclure Unit1.h, je définis donc dans la form2 la variable dll, ainsi lors de la compilation, lorsqu'il s'agit de compiler la dll, il utilisera TForm1 * res, et par conséquent il connaitra tout les membre de la form1 !

Et lorsque je compile l'EXE, il utilisera TForm *res, ce qui évitera des erreurs de compilation vue que j'inclue Unit2.h dans la form1 (pour pouvoir accéder a ces membres également).

Résultat, lorsque je clique sur le bouton qui se trouve dans la form2 de ma dll, avec le code suivant :

res->Edit1->Text = Form2->Caption;

ca marche :D

Au chargement de ma dll dans la form1, j'ai le code suivant:

Form2->res = Form1;

Ce qui permet de renseigner la ressource res de la dll, ainsi j'accède a la form1 de ma dll.

Quant a la communication de la form1 vers la form2, c'est une instruction classique du type :

Form2->Caption = Edit1->Text;

et voilà :D :D :D

Bien sûre je suis persuadé qu'on peux faire mieux mais qu'en pensez-vous ?

Salut !

En supposant que tu développes tout dans le même dossier,
est-ce que tu ne pourrais pas inclure les lignes suivante dans la dll
qui se chargerait de créer une Form2 ?

Code:

---

1 2	include "Unit2.h"; USEFORM("Unit2.cpp", Form2);

---

C'est juste une idée... je vais tester ça de mon coté !

A plus !

En fait c'est déjà ce qui se passe, la form2 est bien dans la DLL.

Par contre j'ai un petit souci, tout fonctionne nikel, du moins dans le programme que j'ai fait juste pour tester, j'attaquerais la transformation du logiciel dés que j'aurais tout compris :wink:

J'ai tout compilé, DLL et EXE et ca fonctionne nikel, l'EXE(form1) appel la form qui se trouve dans la DLL (form2), sachant que la form1 est une MDIForm et form2 une MDIChild, par contre dés que je passe en version finale, dés que je clique sur le bouton qui est censé chargé la DLL et afficher la form2, plantage ! :cry:

Il me dit : "Cannot create form. No MDI Forms are currently active."

c'est un comble car la fenêtre est forcément active vue que je clique sur le bouton !

Enfin, le problème n'a pas l'air de venir de là, j'ai cherché sur le forum et apparemment c'est déjà arrivé, il faudrait inclure les paquets a la compilation, mais le problème c'est qu'une fois compilé, si je le mets sur une machine "vierge", donc qui n'a pas bcb6, il me dit qu'il lui manque vcl.bpi pour s'éxécuter !

Hors j'aimerais bien que mon appli soit la plus légère possible, cad qu'il n'y ait qu'un minimum de dll, en autres les miennes et c'est tout !!!

Si quelqu'un a une idée :?:

Salut !

C'est sans doute un problème au niveau du Owner de la MDIChild qui devrait être la MDIForm,
il me semble (à cause des propriétés et méthodes liées aux Children).

A plus et bon réveillon !

c'est a dire ?

un petit exemple ?

Question subsidiaire pourquoi ca fonctionne en debug et pas en release ?

MErci.

Citation:

---

Envoyé par rudy2

c'est a dire ?

un petit exemple ?

Question subsidiaire pourquoi ca fonctionne en debug et pas en release ?

MErci.

---

Car tu as sans doute des problèmes d'initialisation de variables.

Bonjour,

c'est ce dont je pensais hier soir, en fait voilà le code qui est exécuté dans la DLL juste aprés le chargement de la DLL:

Code:

---

1 2 3 4 5 6 7 8 9

int __stdcall LoadForm(HWND hwnd) { Form2 = NULL; oldhandle = Application->Handle; Application->Handle = hwnd; Form2 = new TForm2(Application); ShowWindow (Form2->Handle , SW_SHOW); return (0); }

---

Et pourtant toujours la même erreur, en fait j'ai remarqué que lorsque je compile en debug, le hwnd a pour valeur 'NULL' et application->Handle également, mais pas lorsque je compile en release 8O 8O

Bizarre quand même, j'ai donc essayé de mettre ces valeurs a 'NULL', mais rien n'y fait, en fait les valeur ne sont pas mise a NULL, comment cela se fait-il ???

Je n'y comprend plus rien !! :( :(

Balises [Code] rajoutées par Ricky81
Pensez y à l'avenir :wink:

Salut !

Citation:

---

Form2 = new TForm2(Application);

---

Normalement le propriétaire d'une MDIChild n'est pas Application mais la MDIForm.

Par contre... chez moi ça fonctionne jusqu'à la libération de la dll où je
me paie une violation d'accès ! Je ne sais plus où mettre la FreeLibrary ?
C'est pas important... je trouverai ça l'an prochain !

D'ici là bon réveillon !

A plus !

Désolé pour la balise code, je n'y avais pas fait attention :?

Oui en fait dans l'appel de la fonction j'ai :

Code:

---

1 2	iRet = ImpFuncDLL(Form1->Handle);

---

Mais ca ne fonctionne pas mieux :(

Bon aprés plusieurs essais, je constate que lorsqu'on compile en debug avec les paquets, cela fonctionne trés bien, mais dés lors que l'on ne construit plus avec les paquets, le code suivant:

Code:

---

Application->Handle = hwnd;

---

ne fonctionne plus :evil: :evil: :evil:

En effet, le Handle ne prend pas la valeur qu'on essaie de lui attribuer !

J'abandonne pour l'instant, ca va me reposer un peu, merci en tout cas a vous tous, et passez une bonne année :D :D :D

Salut !

Il semblerait que tu aies modifié ton programme...

J'ai réussi à trouver une bidouille... (parce que à ce stade j'ai du mal à bien comprendre,
et qu'à mon grand étonnement ça marche !)

Pour ce qui concerne les MDIChild, en fait l'appel au constructeur peut se faire ainsi :

Code:

---

new TForm2(Application->MainForm); //puisque la MainForm n'est autre que la MDIForm

---

Par ailleurs et au cas où tu aurais des problèmes lors de la fermeture du programme,
(ayant voulu tester la génération d'autant de MDIChild dont on a besoin) voici ce que
j'ai fait :

Code:

---

1 2 3 4 5 6 7 8

void __fastcall TForm1::FormClose(TObject *Sender, TCloseAction &Action) { DestroyComponents(); //Solution au bug qui me donnait une violation d'accès (???) if(ChildFormDll != NULL) { FreeLibrary(ChildFormDll); } }

---

Dans la form2 où l'on est censé avoir un bouton pour fermer la fenêtre enfant :

Code:

---

1 2 3 4 5 6

void __fastcall TForm2::SpeedButton1Click(TObject *Sender) { TForm *MdiForm = Application->MainForm; MdiForm->RemoveComponent(this); //la retirer des MDIChildren de la MDIForm Free(); //libérer la mémoire }

---

Toutefois on trouve dans l'aide :

Citation:

---

N'appelez pas la méthode Free d'un objet. Utilisez à la place le mot-clé delete qui appelle Free
pour détruire un objet. Free appelle automatiquement le destructeur de l'objet si l'instance de
l'objet n'est pas NULL. Tout objet instancié à l'exécution qui n'a pas de possesseur doit être détruit
en utilisant delete qui appelle Free, afin que l'objet soit correctement détruit et la mémoire libérée.

---

pourtant ça marche... je n'ai pas voulu faire delete(this) !

A plus !

Salut !

Pour la méthode du bouton... (GAG !!)
J'ai rajouté deux ou trois trucs dans la Form2 et ça m'a donné d'autres bugs au niveau VCL...
Maintenant j'ai donc bien au plus simple (pourquoi ne pas faire ce qui est déconseillé alors
que ça marche) :

Code:

---

1 2 3 4

void __fastcall TForm2::SpeedButton1Click(TObject *Sender) { delete this; // aucun problème alors qu'il m'avait semblé jusqu'à present que "delete this" ??? }

---

Bon... il faut que j'aille ouvrir les huitres... parce que ici... la fête va reprendre !

A plus !

Salut Henderson,

Non ca ne fonctionne toujours pas, en fait ca fonctionne lorsque dans les options de compilation de mon projet la case "construire avec les paquets" est coché, autrement ca ne fonctionne pas !

Le problème c'est qu'a ce moment là il faut obligatoirement inclure le fichier vcl.bpl lorsqu'on distribue l'appli, hors je n'en ai jamais eu besoin depuis que je programme avec bcb6 !

Je continue de chercher, mais a mon avis c'est voué a l'echec cette fois !

Bonne fête a toi :)

Rudy.

Citation:

---

Envoyé par rudy2

Salut Henderson,

Non ca ne fonctionne toujours pas, en fait ca fonctionne lorsque dans les options de compilation de mon projet la case "construire avec les paquets" est coché, autrement ca ne fonctionne pas !

Le problème c'est qu'a ce moment là il faut obligatoirement inclure le fichier vcl.bpl lorsqu'on distribue l'appli, hors je n'en ai jamais eu besoin depuis que je programme avec bcb6 !

Je continue de chercher, mais a mon avis c'est voué a l'echec cette fois !

Bonne fête a toi :)

Rudy.

---

Il me semble qu'n a déjà eu un cas similaire où l'application ne fonctionnait pas comme elle devait lorsque "construire avec les paquets" était décoché. Il s'est avéré que des variables qui n'avaient pas été initialisées ne prenaient pas les mêmes valeurs dans les 2 configurations.

En espérant que ca puisse te mettre sur une piste ... (Trap D l'a déjà évoqué précédement)

Effectivement tu as raison, j'ai pu remarqué que lorsque l'instruction suivante est exécuté :

Code:

---

Application->Handle = hwnd;

---

ca fonctionne avec la compilation des paquets, mais pas sans, cad que la valeur de hwnd n'est jamais attribué a Application->Handle, elle reste inchangé !

C'est a devenir fou :twisted: :twisted: :twisted:

Salut a tous,

J'ai enfin trouvé la solution au problème de la mdichild qui est dans la DLL (Form2), voilà le code :

Code:

---

1 2 3 4 5 6 7 8 9

int __stdcall LoadForm(TApplication *app) { Oldapp = Application; Application = app; BD = NULL; BD = new TBD(Application); ShowWindow (BD->Handle , SW_SHOW); return (0); }

---

Comme vous pouvez le voir, je passe en paramètre un TApplication *app, je remplace le Application de la DLL, que je sauvegarde d'abord, par celui qui est passé en paramètre, et là tout fonctionne avec ou sans les fameux paquets !!! :D :D :D

Par contre autre souci, je cherche depuis quelques heures déjà mais je ne trouve pas si vous avez des pistes a me proposer ... :(

Voilà le problème, en fait ma form2 qui est dans la DLL contient des fonctions par exemple ceci :

Code:

---

1 2 3 4

void __fastcall TForm2::test() { ShowMessage("Hello"); }

---

Simple jusque là ! Mais pourtant quand j'essaie d'accèder a un contrôle de la form2, peu importe le contrôle un bouton un tedit ..., pas de problème, par contre si j'essaie de faire un appel a la fonction, la compilation echoue en me disant "unresolved external __fastcall 'TForm2::test() ..." :(

Est-ce que c'est possible de faire appel a cette fonction depuis l'extérieur ? Est-ce moi qui ai oublié quelque chose ?

Si vous avez des pistes, je suis preneur :!: :!:

Salut

Citation:

---

Simple jusque là ! Mais pourtant quand j'essaie d'accèder a un contrôle de la form2, peu importe le contrôle un bouton un tedit ..., pas de problème, par contre si j'essaie de faire un appel a la fonction, la compilation echoue en me disant "unresolved external __fastcall 'TForm2::test() ..."

Est-ce que c'est possible de faire appel a cette fonction depuis l'extérieur ? Est-ce moi qui ai oublié quelque chose ?

---

Qu'appelles-tu faire appel à la fonction de l'extérieur, dans le programme appelant ta Dll ? Dans ce cas il y a, il me semble un problème de conception, non ?

Oui je parle effectivement du programme appelant la DLL, pour les composant je n'ai pas de souci, c'est sur les fonctions uniquement !

Qu'entend tu par problème de conception ?

Est-ce que ce ne serait tout simplement pas possible ?

Tout compte fait, je me demande si c'est vraiment possible d'utiliser des fonctions d'une class se trouvant dans une DLL !!!

Mais pourquoi les composants ne posent pas de problème a ce moment là ?

Il me semble avoir vue quelque chose concernant les fonctions d'une class dans les DLL, mais je ne retrouve pas ou ?

Si quelqu'un a une idée ...

Le programme appelant n'a pas à mon avis à connaître les détails de l'implémentation de la Form de la Dll. Topujours à mon avis, il devrait demander à la Dll d'effectuer certaines actions mais sans référence à la Form par exemple
Dans le programme appelant :

Code:

---

DllAction1();

---

la fonction étant définie dans la Dll par

Code:

---

1 2 3 4

void Action1(void) { Form1->Ok(); }

---

Il faut bien sur ajouter les déclarations permettant d'exporter Action1.

Oui j'avais quelque doute, mais vu que je peux accéder aux variables et aux composant, je pense qu'il doit bien avoir un moyen d'accéder aux fonctions également, mais bon ...

Si je doit procéder comme tu dit, je pense que j'ai du pain sur la planche, vue que c'est effectivement la seule solution qui fonctionnerait pour l'instant, vue le nombre de modules que je souhaite mettre en DLL, j'en ai pour au moins deux semaines :( :(

Salut !

Tu es bien sûr d'avoir enregistré les modifs puis reconstruit la dll?
Chez moi ça marche :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void __fastcall TForm2::FormClick(TObject *Sender) { MessageCoucou(); }   void __fastcall TForm2::MessageCoucou() //déclarée en public { Application->MessageBox("Il faut que je passe l'aspirateur ! Mais...!", "Test", MB_OK | MB_ICONEXCLAMATION); }

---

Par contre, moi j'ai eu un gros bug à la fermeture du programme !
J'ai du rajouter ceci dans la dllEntryPoint :

Code:

---

1 2 3 4

if(reason == DLL_PROCESS_DETACH) { Application = Oldapp; }

---

Autrement pour titiller la MDIForm, il suffit de caster par :

Code:

---

Application->MainForm->...;

---

Donc tout ce qui relève de TForm (et non de Form1), comme Tile()... etc..


A plus !

Citation:

---

Tu es bien sûr d'avoir enregistré les modifs puis reconstruit la dll?

---

Oui, mais en fait il s'agit d'appeller la fonction qui se trouve dans Form2 depuis Form1 (l'EXE) !

Mais j'ai finalement trouvé, en fait tout simplement grace au tuto. de LFE, j'avais la réponse sous les yeux depuis un moment, il "suffit juste" d'exporter la class qui se trouve dans la Form2, en mettant dans le .H ceci :

Code:

---

1 2 3 4 5

#ifdef __DLL__ #define IMPORT_EXPORT __declspec(dllexport) #else #define IMPORT_EXPORT __declspec(dllimport) #endif

---

Simple et efficace, car ca fonctionne :D :D

Par contre pour ca :

Citation:

---

Par contre, moi j'ai eu un gros bug à la fermeture du programme !
J'ai du rajouter ceci dans la dllEntryPoint :

---

J'ai eu le même problème a un moment donnée, je l'ai résolu en mettant ma compil en mode Release :idea:

Plutôt bizarre non ?

Donc maintenant tout fonctionne, enfin je fait encore quelques modifs et je vous poste le code que j'ai utilisé pour les différents problème que j'ai eu.

Merci a tous et a bientôt. :D :D

PS: Bravo LFE pour le tuto. sur les DLL sans lui je n'aurais rien fait du tout ! :roll: