Controle d'interface par une DLL (ajout, retrait de composants)
cs_kokonut
Messages postés17Date d'inscriptiondimanche 16 mars 2003StatutMembreDernière intervention27 mai 2005
-
23 mai 2003 à 15:59
cs_kokonut
Messages postés17Date d'inscriptiondimanche 16 mars 2003StatutMembreDernière intervention27 mai 2005
-
31 mai 2003 à 23:02
Bonjour,
J'ai recours à l'utilisation de DLLs pour un programme sous Delphi (bien sûr) et je me pose la question suivante :
Est-il possible, pour un programme, de faire appel à une DLL pour créer un bouton (ou un autre composant) sur une des ses Forms ?
Je ne parle pas évidemment du cas où on a créer cette form dans la DLL on a :
- le programme et ses forms
- une DLL (toute sympa et volontaire) qui crée des boutons
L'objectif étant de ne pas repousser toute l'interface dans des DLLs ou autre mais par contre de se réserver le droit qu'un programme puisse faire appel à une DLL qui aurait en quelque sorte des pointeurs (ne fuyez pas) vers les form du prog.
Si il y a quelqu'un qui sait, ça m'aiderait beaucoup, je n'ai plus qu'1 mois LOL.
:kisses)
Ciao
:shy) --- Kokonut ... leaves in Delphi Heaven --- :shy)
A voir également:
Controle d'interface par une DLL (ajout, retrait de composants)
cs_Delphiprog
Messages postés4297Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 9 janvier 201332 24 mai 2003 à 00:27
Bien sur que c'est possible, mais quel en serait l'intérêt s'il faut lier toutes les unités de base Windows, Messages, etc et SURTOUT les unité Forms et stdctrls dans la DLL ?
Surtout que pour créer un bouton, il faut, au minimum, connaitre : le propriétaire, le parent, la position, le caption, les adresses des méthodes à rattacher au bouton créé (OnClick, OnDblClick, and so on...). Donc, ta DLL va grossir tout d'un coup.
Tu vas t'embarquer dans une galère pour, au final, revenir au point de départ.
Cette technique ne présente d'intérêt, à mon humble avis, que dans le cadre de la réalisation de plug-ins.
En revanche, l'utilisation de packages, chargés dynamiquement, ne présente pas tous les inconvénients des DLL. Le code des unités citées plus haut ne sera pas inclus une seconde fois et tu as accès à l'objet Application tout comme aux unités de l'application principale référencés dans les unités des packages. Bénéfice net, une programmation facilitée, un code plus facile à déboguer.
Et comme ce genre de développements ne servira surement pas à d'autres applications, il y a plutôt intérêt à opter pour les packages.
cs_kokonut
Messages postés17Date d'inscriptiondimanche 16 mars 2003StatutMembreDernière intervention27 mai 2005 24 mai 2003 à 12:43
Salut Delphiprog et merci.
C'est exactement mon cas, j'ai besoin de réaliser en quelque sorte un système de plug-ins. Le logiciel sur lequel je travaille à l'heure actuelle est destinée à une entreprise pour laquelle je travaille temporairement (je suis stagiaire). Néanmoins, le suivi à court terme après la fin de mon stage est important (voir sur le long terme).
Comme je n'ai pas envie de mettre toute l'interface dans une dll (vu que l'interface que j'ai déjà me satisfait), j'aimerai juste connaitre la méthode qui me permettrai de laisser une porte d'entrée à une DLL pour qu'elle puisse en modifier le contenu à posteriori (le parent, le propriétaire et le nom de l'objet me suffirait je pense).
C'est juste de la prévention, parce que derrière j'ai des threads qui travaillent et j'ai peur du deadlock LOL. Et puis je cherche toujours à apprendre plus ;) .
Par contre si quelqu'un connait un bon tutorial sur le sujet ou sur les packages chargés dynamiquement, je lui serai très reconnaissant.
Merci
:kisses)
Ciao
:shy) --- Kokonut ... leaves in Delphi Heaven --- :shy)
cs_kokonut
Messages postés17Date d'inscriptiondimanche 16 mars 2003StatutMembreDernière intervention27 mai 2005 24 mai 2003 à 14:22
Re-Salut et merci.
Il a l'air d'être intéressant et je me mettrai à jour pour mon prochain projet. Par contre, si j'ai bien compris (j'ai survolé pour l'instant parce que mon imprimante est morte) il faudrait que je package mon interface. Vu qu'il me reste 1 mois et que je dois implément mes 5 threads (synchronisés à l'aide de BAB ... asynchro <-> bloquant) et le système client/serveur, un petit indice, coup de pouce, pour la solution DLL serait la bienvenue (enfin si ça ne te prends pas trop de temps).
Merci.
:kisses)
Ciao
PS : pour info, le prochain projet en question sera orienté 3D / Intelligence Artificielle ... donc je risque d'avoir besoin d'aide. Par contre ya pas de prob, si quelqu'un cherche des infos sur le sujet ... je peux peut être aider.
:shy) --- Kokonut ... leaves in Delphi Heaven --- :shy)
Vous n’avez pas trouvé la réponse que vous recherchez ?
cs_Delphiprog
Messages postés4297Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 9 janvier 201332 24 mai 2003 à 14:38
Euh, c'est quoi "BAB" ?
Sinon, ce n'est pas l'interface qu'il faut packager, mais juste les unités que tu inclus dans ta DLL.
De la même manière que pour une DLL, il faut exporter les routines que tu souhaites rendre visibles de l'extérieur (clause Exports identique).
De plus, pour synchroniser les threads, ça facilite considérablement la tâche dans la mesure où tu as accès aux méthodes de l'objet Application et au MainThread. Ce qui n'est pas le cas avec une DLL.
On peut exécuter des threads dans une DLL, mais je ne vois pas trop comment les synchroniser avec le thread principal de l'application hôte. Il faudrait creuser la question (si c'est absolument nécessaire, évidemment).
May Delphi be with you
C'est en anglais et c'est très long, mais c'est très complet.
:big)
Un BAB c'est un "buffer" bidirectionnel qui fonction d'un côté en mode asynchro (par exemple côté VCL) et de l'autre en mode bloquant (donc un Worker thread).
Sinon je vais regarder en détail pour les packages ... mais ... juste pour info ... pour mourir moins bête :shy) :blush) ... j'aimerai bien savoir comment on peut faire pour zigouiller un bouton ou autre à partir d'une DLL ... mais promis juré la prochaine fois c'est du package ... LOL :clown) .
:kisses)
Ciao et merci
:shy) --- Kokonut ... leaves in Delphi Heaven --- :shy)
cs_kokonut
Messages postés17Date d'inscriptiondimanche 16 mars 2003StatutMembreDernière intervention27 mai 2005 31 mai 2003 à 23:02
Pour ceux qui sont intéressés par la réponse ... voici la solution.
Enoncé du problème :
- une application avec une Form1 et un bouton
- une dll avec une Form2 et un boutton
L'objectif est que lorsque l'on clicque sur le bouton de la Form2 (donc appartenant à la DLL) que l'on puisse enlever le boutton de la Form1 (côté application donc) et en créer un autre.
Tout d'abord on crée l'application et on ajoute notre bouton, quand on clicque sur celui-ci, il va charger dynamiquement la DLL (je ne reviens pas sur cette méthode) et faire appel à la fonction :
procedure charget_dll ( Hdle : THandle; Forme : longint);
procedure charget_dll ( Hdle : THandle; Forme : longint);
var F : TForm;
But : TButton;
begin
Application.Handle := Hdle;
F := TForm (Forme);
But := TButton( F.FinComponent('Button1') );
But.Free;
With TButton.Create(F) do
begin
Name := 'Boutton';
ParentFont := False; // Très important sinon erreur TFont
Left := 50;
Top := 50;
ParentWindow := F.Handle;
Caption := 'C ok';
end;
end;
Et voilà ... ça devrait marcher.
Il est conseillé d'utiliser ParentWindow et non pas Parent car en utilisant Parent votre bouton sera bien attribué à Form1 mais il ne sera pas visible ... même si vous mettez Visible := True ... et il est bel et bien présent car en demandant le nombre de composants de Form1 ainsi que leurs noms ... il y est. Donc utilisez ParentWindow ;)
Sinon ... Merci à Delphiprog pour le coup de main
Ciao
:shy) --- Kokonut ... leaves in Delphi Heaven --- :shy)