Discussion :

[teska]

Bonjour,

Dans mon application, je crée dynamiquement un TFrame et je lui indique que son Parent est un TPanel déjà existant, ce qui marche parfaitement bien. Par contre, maintenant que je veux mettre ce TPanel dans une DLL et le créer dynamiquement depuis la DLL, j'ai un message d'erreur "Le controle XXX n'a pas de fenêtre parente".

J'ai essayé depuis en assignant au Handle de l'application créée par la DLL le Handle de l'application .exe appelante, en passant une TForm existante en paramètre du Create de mon TFrame pour qu'il ait un gestionnaire, en affectant le handle de cette même TForm au ParentWindow du TFrame, et je tombe un peu à court d'idées.

Sur le net et sur les tutorials je n'ai pu trouver que la création d'une TForm via une dll, et effectivement ça fonctionne très bien. Au pire je pourrais créer la TFrame dans une TForm et faire en sorte que la TForm suive le déplacement de la TForm parent mais c'est plutôt du bidouillage. N'y aurait-il pas plutôt une solution au problème que je rencontre ?

J'ai remarqué d'ailleurs dans la FAQ un article sur : Pourquoi j'obtiens le message "Impossible d'affecter TFont à TFont" ?, et dans ce post l'auteur indique comment résoudre ce problème (que j'ai eu et que j'ai résolu, merci à lui !) mais ça ne résoud pas ce nouveau problème évoqué plus haut. Je ne trouve pas d'autres informations à ce sujet, donc si quelqu'un aurait ne serait-ce qu'une idée de ce qu'il manque pour que ça fonctionne, je suis preneur !

Merci d'avance

[Paul TOTH]

quel est donc l'intérêt de créer un TFrame dans une DLL ?!

moi y'a des choses qui m'échappent

Alors, soit tu utilises des Packages et puis voilà !

soit tu parts sur la route sinueuse de ceux qui ne veulent pas faire comme c'est indiqué dans la doc, et tu vas passer du temps sur les forums

Sinon, que ce soit un TFrame ou un TForm, la méthode CreateParented sert justement à créer un TWinControl sur un composant Windows non-Delphi.

Tu vas me dire que ton composant EST un composant Delphi, je te dirais oui MAIS, car il y a un mais, soit tu utilises des packages afin de pouvoir partager tes composants entre l'exe et ta DLL/Package, soit tu ne le fais pas, et pour l'un, les composants de l'autre ne doivent être vus QUE comme des composants Windows, c'est à dire un HWnd obtenu par Form1.Handle ou Frame1.Handle selon le cas.

On ne peut pas avoir le beurre et l'argent du beurre

[Clorish]

J'ai, fut un temps, resolut le probleme en utilisant la methode setPArent de windows ... mais on est confronte a d'autres petits soucis ... notement au niveaux de l'utilisation des anchors ....

Sinon je viens juste, il y a quelques jours de penser a un truc sympas : Creer une classe TComponentFactory, qui creer, et parametre dynamiquement des elements graphiques comme des TButtons, TLabels,etc ... le tout pilotable depuis une serie d'interfaces.

DE cette maniere, tout composant enregistré dans la factory peut etre manipule depuis la dll, et de meme, la dll peut instancier des composants directement dans l'exe .....

Plutot que de placer le code graphique directement dans la dll, l'interface est gerer dans l'exe via des scriptes de conceptions ....

Un peut utopique peut etre mais sympas a mon avis
Par contre, peut etre un peu lourd ... vu qu'il va faloir integrer dans le code tous les composants graphiques

A voir mais ca peut donenr des idees

[Clorish]

soit tu parts sur la route sinueuse de ceux qui ne veulent pas faire comme c'est indiqué dans la doc, et tu vas passer du temps sur les forums

Au passage .. c'est ecrit quoi dans la doc ?

[Paul TOTH]

Au passage .. c'est ecrit quoi dans la doc ?

que la VCL n'est pas conçue pour être utiliser entre DLL et EXE

d'ailleurs Delphi n'offre aucune possibilité d'exporter une classe Delphi d'une DLL vers un EXE...sauf à utiliser des packets qui sont des DLL spécialement étudiée pour cela

Sinon ton idée de placer tous dans l'EXE est intéressante, mais ça interdit l'ajout d'un nouveau composant J'ai étudié vaguement la question avec l'idée d'une Remote VCL. A l'image d'un serveur Web, le serveur "remote VCL" fournit des DFM que le client "remote VCL" peut afficher

[skywaukers]

Bonsoir,

sans hésiter tu dois utiliser les packages, c'est souple et ça marche.

@++
Dany

[aityahia]

il y a un tuto sur développez écrit par Sébastien Doeraene(sjrd),Éric Leconte(Clorish) sur l'utilisation des plugins tu peut t'inspirer
ici

[Paul TOTH]

il y a un tuto sur développez écrit par Sébastien Doeraene(sjrd),Éric Leconte(Clorish) sur l'utilisation des plugins tu peut t'inspirer
ici

l'utilisation des Plugin est aussi un des deux chapitres du livre "Delphi 7 Studio" disponible en ligne

[anapurna]

salut

Tiens ca me dit quelque chose ce truc ...bizard non ?
a l'utilisation de pluggin dans une appli
suffit de faire une recherche sur google + delphi et tu as une liste imposante


@+ Phil

[Paul TOTH]

salut

Tiens ca me dit quelque chose ce truc ...bizard non ?
a l'utilisation de pluggin dans une appli
suffit de faire une recherche sur google + delphi et tu as une liste imposante


@+ Phil

sans oublier ngscan

[teska]

Dans ce cas, je vais regarder les packages de plus près, je ne m'étais jamais penché sur la différence entre un package et une DLL. Au moins je vois où chercher

Merci beaucoup !

[Clorish]

J'apporte une precision sur les Paquets :
Ce sont des Dlls, specialisé pour delphi, c'est a dire que borland a modifié certaines choses pour les rendre plus accessible via des applciations Delphi.

Par contre, utiliser des Paquets en tant que paquets (car il peuvent etre utilisees comme des dlls), il est necessaire de fournir en plus de tes paquets, au moins les paquets VCL, RTL, et aussi tout ceux dont tu utilises au moins une ligne de code.

Ca peut vite monter assez haut ....
C'est cette restriction qui m'a fait abandonner les paquets ...

[aityahia]

Ca peut vite monter assez haut ....
C'est cette restriction qui m'a fait abandonner les paquets ...

vous avez vous même écrit le tuto sur l'utilisation des paquet, j'ai une application volumineuse que j'ai pensez fragmenter en module en utilisant des paquet,alors je me vois hésitant les dll son meilleur .

[Clorish]

Oui j'ai ecrit un bon tuto a l'epoque

Disons que comme toi, je voulais inclure des composants VCL dans une dll. C'est suite a une tres longue discussion sur ce forum qu'on est arrivé a creer ce tuto.

Depuis mes connaissances ont changées et a chaques fois que les paquets s'imposait pour moi, j'ai ete refroidi par la contrainte de fournir les autres BPLs.

A savoir :
Quand on compile un paquet, il inclut le code de chauqes unitees qu'il reference. Pour chaques unitées qui en appele une autre, si cette derniere est inclue dans un paquet, il va liser ce paquet a celui en cours de developpement.
Ce 2e paquet est donc necessaire pour faire tourner l'application.

Un des paquets minimum est RTL.
Des qu'on utilise la VCL il faut lier le paquet VCL.
Si tu utilise un compo Indy, tu doit fournir le paquet Indy correspondant.
Pour Jedi c'est pareil,
Ainsi que pour tous les composants que tu as pu telecharger a droite et a gauche.

Prenons le cas simple suivant : Ton paquet ne fait pas appel a la VCL ( a aucun moment) mais fait du traitement sur des Couleurs.
Tu propose une methode avec un parametre TCOlor, que l'applciation pourra renseigner. TColor est defini dans Graphics.pas, lui meme faisant parti du package VCL ....
Inclure toute la VCL pour seulement un Type ... je trouve ca lourd

Autre point, lié au precedent, lorsque l'on compile une application, Delphi fait le tri entre le code utilisé et celui qui ne l'est pas. Il n'inclut donc que les composants/fonction utilisée.
Le BPL lui contient tout. Donc fournir un paquet c'est fournir tous le code de toutes les unitees qu'elle contient.
Moi ca me gene ... car ca fini par faire beaucoup.

L'interet principal des BPL c'est de pouvoir partager le code de petites applications, faisant appel a beaucoup de paquets personalisés.

Une Dll est moin pratique a gerer, surtout pour la gestion VCL. Mais elle a l'avantage de ne contenir que le code effectif.
Donc avant de basculer sur une gestion par paquets, je me pose toujours la question : Comment je peux gerer la VCL hors de ma Dll .... si je trouve, je garde les Dlls.

Maintenant pour la gestion VCL dans une Dll, c'est tres faisable a partir du moment ou tu gere une form. Ca c'est facile. Mais si le parent de ton composant n'est pas une form de ta dll ca deviens vitre assez complexe meme si avec setParent de windows ou la prop parentWindows de TCOntrol, on arrive a faire quand meme pas mal de choses ...

[Paul TOTH]

pour mettre mon grain de sel

personnellement je fais TOUJOURS des application monolithiques

c'est à dire sans DLL, car je n'ai jamais trouvé l'intéret de découper mon application.

Si celle-ci devait devenir trop volumineuse pour une raison ou une autre, je commencerais par regarder ce qui prend de la place.

si ce sont des images :
- vérifier le format pour réduire au mieux leur taille
- éventuellement les placer en ressource, et pourquoi pas alors dans une DLL de ressource, ça ne pose aucun soucis particulier (si ce n'est le chargement à la main de la ressource...encore que j'avais développé à une époque un dérivé de TImage qui s'appuie sur un nom de ressource...mais c'est une autre histoire )

si c'est du code :
- voir si une portion du code peut être identifié comme indépendant du reste et former une entité fonctionnelle que je puisse place dans une DLL
- dès lors, définir une API indépendante de Delphi pour que ma DLL soit réutilisable
** c'est à dire, soit de simples fonctions, quitte à utiliser en interne des objets, mais en ne communiquant que des "Handle" opaques
** soit en travaillant avec des Interfaces !


mais en fait, à ce jour, je n'ai jamais eu besoin de découper mes applications

[aityahia]

pour mettre mon grain de sel

personnellement je fais TOUJOURS des application monolithiques

c'est à dire sans DLL, car je n'ai jamais trouvé l'intéret de découper mon application.

Si celle-ci devait devenir trop volumineuse pour une raison ou une autre, je commencerais par regarder ce qui prend de la place.

une telle application est parfaite,comme moi j'ai une contrainte de volume qui est du au nombre de fiche et important, mon application est multi-modules (Comptabilité,Stock,Commercial,GRH) il y que mon login qui va déterminé mes role d'où l'intérêt de partager mon application , je charge uniquement le module voulu.

[Paul TOTH]

ok, mais quand tu dis "charger", faut bien voir que les DFM ne sont chargés que lorsque tu crées les instances de fiches.

Regarde plutôt l'occupation mémoire de l'application en cours d'execution que le nombre de fiche existantes. Je ne suis pas certain que le partage y gagne.

Ensuite, tu peux avoir une application modulaire, dont les modules optionnels sont payants...et alors tu as besoin en effet de fractionner l'application. C'est un cas de figure auquel je n'avais pas songé.

Mais les modules sont assez indépendant les uns des autres non ? Je veux dire par là, que la fiche GRH ne vas pas changer si tu as ou pas l'option Compta...ce sont des fiches indépendantes non ?

Dès lors il te faut définir un modèle d'interaction entre ton appli centrale et ses plugins...il me semble que tu gagnerais à créer un dérivé de TFrame (ou TForm) comme base de tes plugins, et un dérivé de TForm dans ton appli qui serait le conteneur du TFrame...en mettant dans l'un et l'autre "ce qu'il faut" pour que ça fonctionne

en localisant le problème sur ces deux composants, tu peux développer le reste avec pour seul contrainte d'utiliser ce conteneur.

Et le plus simple c'est de coller des Interfaces aux deux

IApplicationForm = le Tform de l'application
IPluginFrame = le TFrame de la DLL

et tu déclares dans tes interfaces tout ce dont tu as besoin pour faire interagir les deux

et ta DLL n'a plus qu'à exporter la fonction

Code :

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

1
2
 
function GetPlugin(Owner:IApplicationForm):IPluginFrame;

avec des trucs du genre

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
type
 IApplicationForm=interface
// ajout d'un menu dans l'application
  procedure AddMenuItem(Caption:string; id:cardinal);
 end;
 
 TPluginFrame=interface
// appel de la méthode Click dans la DLL
  procedure OnMenuClick(id:cardinal);
 end;

ce qui donne dans l'application

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
17
18
19
20
21
22
23
24
 
type
 TForm2=class(TForm, IApplicationForm)
  fPlugin:IPluginFrame;
  procedure AddMenuItem(Caption:string; id:cardinal);
  procedure OnMenuClick(Sender:TObject);
 end;
 
// le constructor invoque la DLL pour obtenir fPlugin
 
procedure Tform2.AddMenuItem(Caption:string; id:cardinal);
var
 m:TMenuItem;
begin
 m:=Form1.MainMenu.Items.Add;
 m.Catpion:=Caption;
 m.Tag:=id;
 m.OnClick:=OnMenuClick;
end;
 
procedure TForm2.OnMenuClick(Sender:TObject);
begin
 fPlugin.OnMenuClick(TMenuItem(Sender).Tag);
end;

je te laisse imaginer la suite

[Clorish]

Tiens je suis d'accord avec toi Paul
J'opterais pour un conteneur unique.

Quoi que l'on rentre jsutement dans le cadre de la gestion VCL via TForm ... donc pour moi rien n'empeche de developper un TForm dans la Dll et de le manipuler via des fonctions ou une interface depuis l'exe ...

L'avantage des TForm, c'ets que generalement, ils n'ont pas de parents, donc ca regle le probleme principal que je rencontre : La gestion de l'affichage lié a uen affectation du parent. Comme dit plsu haut, ParentWindows regle certains pbs mais pas ceux lié au parentFont et autres PArentXXXX et encore les ancres ...

Sinon j'aimerais avoir un detail de plus : Tu declare un TFrame dans la Dl let un TForm dans l'exe si j'ai bien compris. Comment affecte tu le TFrame au TForm ? J'ai pas trop compris ce passage
(et ca m'interesse )

[Paul TOTH]

Tiens je suis d'accord avec toi Paul
J'opterais pour un conteneur unique.

Quoi que l'on rentre jsutement dans le cadre de la gestion VCL via TForm ... donc pour moi rien n'empeche de developper un TForm dans la Dll et de le manipuler via des fonctions ou une interface depuis l'exe ...

L'avantage des TForm, c'ets que generalement, ils n'ont pas de parents, donc ca regle le probleme principal que je rencontre : La gestion de l'affichage lié a uen affectation du parent. Comme dit plsu haut, ParentWindows regle certains pbs mais pas ceux lié au parentFont et autres PArentXXXX et encore les ancres ...

Sinon j'aimerais avoir un detail de plus : Tu declare un TFrame dans la Dl let un TForm dans l'exe si j'ai bien compris. Comment affecte tu le TFrame au TForm ? J'ai pas trop compris ce passage
(et ca m'interesse )

rahlala

j'ai expliqué ça déjà, ici ou dans un autre thread, je sais plus

si je reprend la logique des interfaces ci-dessus tu auras

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
17
18
19
 
type
 TDLLFrame=class(TFrame, IPluginFrame)
  fOwner:IApplicationForm;
  constructor Create(AOwner:IApplicationForm); reintroduce;
 end;
 
constructor TDLLFrame.Create(AOwner:IApplicationForm); 
begin
 fOwner:=AOwner;
// en considérant que IApplicationForm.GetHandle retourne TForm.Handle :D
 CreateParented(fOwner.GetHandle);
end;
 
 
function GetPlugin(Owner:IApplicationForm):IPluginFrame;
begin
 Result:=TDLLFrame.Create(Owner);
end;

ça illustre bien mon propos précédent d'ailleurs, tout ce dont on a besoin doit se trouver dans l'une ou l'autre des deux interfaces

[sjrd]

C'est marrant comme les pensées changent Quand Clorish et moi avons écrit notre tuto, lui il optait pour les paquets, moi pour les interfaces.

Maintenant il préfère passer par interfaces, et moi je travaille actuellement avec des paquets

Mais en fait, j'utilise des paquets, et je n'ai pas peur de déployer rtl.bpl et vcl.bpl, parce que mon "application" comporte en fait 4 programmes. Donc le gain de place est vite fait. Même si je pers de la place parce que je n'ai pas le bénéfice du lieur qui élimine ce dont je n'ai pas besoin. Car je réutilise 4 fois le même code au lieu de le quadrupler dans mes 4 programmes.

Et après la gestion de plug-in à coup de paquets est vraiment simple et puissante.