Discussion :

[floppy64]

Bonsoir,

J'aimerais savoir comment interagir sur une forme principale depuis une(des)
bibliothèque(s) dynamique(s).
Imaginons un exe principal qui soit un container chargé de l'affichage :
- de la forme principale,
- du squelette du menu
et qui doivent prendre en charge des overlays.

Comment ces derniers peuvent ajouter à la forme principale des composants (dans mon cas une frame avec composants) et des extensions au menu ?

En bref, comment modifier (communiquer avec) les composants de la forme principale depuis une DLL uniquement par programmation.

Merci pour toute réponse !

[Altau]

Peut être en ayant préalablement appelé une fonction de la DLL par laquelle l'exe lui aura communiqué son handle ou un mutex permettant à la DLL d'envoyer en retour un message à l'exe ?

[floppy64]

Peut être en ayant préalablement appelé une fonction de la DLL par laquelle l'exe lui aura communiqué son handle ou un mutex permettant à la DLL d'envoyer en retour un message à l'exe ?

En laissant de côté le mutex (trop versatile), je retiendrais la technique du 'handle'.
Mais comment faire sous BCB ?
Quelqu'un(e) saurait-il me proposer un exemple ?

[Altau]

Une fois que tu as imaginé un protocole d'échange entre ta DLL et ton EXE, tu fais envoyer par ta DLL un message à l'EXE (grâce à son handle que tu as préalablement récupéré) par un SendMessage ou un PostMessage dans lequel le wParam et le lParam indiqueront à l'EXE ce qu'il doit faire.

[floppy64]

Merci à Mattetfamilly et à Altau pour leurs réponses !

J'ai testé les 2 façons de faire qui sont totalement fonctionnelles.

Celle d'Altau est "meilleure" dans le cadre d'une portabilité du code sur un autre compilateur Windows.
Mais je suis accroc à Borland depuis la fin de mes études en 1992 (M...e, je viens de rendre compte que je prends un coup de vieux) aussi je conserve la technique de Mattetfamilly : Passage de paramètre(s).

D'ailleurs je tiens à m'excuser, il ne fallait que passer un pointeur : J'ai posté plus vite que de réfléchir. Mea Culpa ! (Je suis tellement pris dans mon dev que les trucs C++ basiques me semblent toujours liés à l'IDE et je ne vois pas plus loin que mon nez !)

Encore merci Mattetfamilly car malgré tout, je me serais embué dans des codes inextricables en pestant contre l'IDE de Borland que, je dis de nouveau, j'adore envers et contre tous

Mais merci à tous les 2. Et si je devais passer sur un autre compilateur, promis Altau, ta solution sera mienne !

Pour répondre à ta question Mattetfamilly, je développe un programme de reconnaissance hard/soft dans le style de Sandra, Aida32(actuellement Everest) ou du moins connu mais pourtant le meilleur PC Wizard (Freeware de Franck Delattre, concepteur de CpuZ, et Laurent Kutil. Pour ceux qui liront ce post n'hésitez pas à le télécharger !) et par conséquent mon programme est amené à évoluer constamment.

Mon programme fonctionne actuellement à merveille mais il a trop mangé de burgers lol (Reconnaissance CPU, Chipsets, SMBUS, DMI, SPD etc. ainsi que le software) bref il explose en taille.
Aussi je souhaiterais créer un programme "container" qui passerait aux DLL (confinement des fonctionnalités) des infos types telles que les pointeurs de menu, de main frame et autres composants adjacents afin que l'appli charge ces DLL, si les fonctions exportées sont reconnues, et que ces DLL se chargent du reste de manière autonome.

Avantages :
1 - Mise à jour ciblées,
2 - Implémentation facilitée d'un mode DEBUG,
3 - Portablité (MS Win) simplifiée,
4 - Offre d'un mode 'Plug-in'.
Euh et qui plus est, un poids de download allégé pour les clients RTC bien qu'ils soient de moins en moins légion. Mais en dev il ne faut léser personne.

Encore merci à tous 2 !

[Mattetfamilly]

J'entrevois une possibilité:

Dans la DLL tu dois inclure le fichier d'entête de la Form sur laquelle la DLL doit agir (#include unit1.h, si c'est le nom du fichier de ta Form1, Form principale). Ensuite dans les paramètres de la fonction de la DLL, tu dois passer un paramètre qui correspond à ta form principal.
Si ta forme principale s'apelle Form1, sa classe s'apelle TForm1.
Dans ce cas, la fonction de la DLL sera du type:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
bool MyDLLFunction (TForm1 *MyFormInDLL, bool Hiding, TColor NewBackGroundColor)//Seul le paramètre TForm1 est obligatoire, les autres sont là pour l'exemple
{
//Ton code
//Ci après un code exemple:
MyFormInDLL->Color=NewBackGroundColor;
MyFormInDLL->Label1->Caption="Couleur arrière plan modifiée par la DLL";
MyFormInDLL->Caption=MyFormInDLL->Caption+" Couleur modifiée par DLL";
MyFormInDLL->Visible=Hiding;
MyFormInDLL->Memo1->Lines->Add(MyFormInDLL->Edit1->Text);
MyFormInDLL->Memo1->Lines->Add(MyFormInDLL->Edit2->Text);
MyFormInDLL->Memo1->Lines->Add(IntToStr(MyFormInDLL->Memo1->Lines->Count));
return MyFormInDLL->Memo2->Modified;
}

Toutefois, ce type de lien n'a pas d'intérêt:
Tu veux agir sur ta Form principale: autant inclure directement la fonctionnalité dans l'exécutable. La DLL n'est pas exploitable par une autre application que celle ci.

En revanche, cela peut avoir un intérêt si ce n'est pas ton application qui maîtrise la DLL en question en faisant appelle à elle. Cela peut devenir intéressant lorsque tu veux intervenir sur une application à partir d'une autre en modifiant les composant de type TEdit. Mais une fois encore la programmation est trop orientée vers une application pour être intégrée à une DLL.
La DLL est une bibliothèque de fonctionnalité qui serve d'extension à ton application. Généralement la DLL est utilisée pour génrer des fonctions courantes partageables entre différents programmes. Cette fonctionnalité ne sont pas recompiler à chaque fois que tu crées un nouveau programme. exemple: cryptage / décryptage de données / de fichier ou bien protocoles de communication...

Peux tu décrire plus précisément ce que tu cherche à faire?

@+
Mattetfamilly.