Discussion :

[Pedro]

lol je sais c'est de la m****,

Ah! Pourtant on m'a dit que c'était plus propre

toutefois, essayez de libèrer l'objet vous même ...

Mais je ne comprends pas. Il n'y a pas de méthode de destruction sur une interface! Quand à l'objet qu'elle contient (une TForm), je la détruis juste après son appel...

[pepi22]

La classe TTest ...

[pepi22]

Par précaution, les mêmes conventions d'appel sont utilisé?

[Pedro]

La classe TTest ...

Mais justement! Cette classe n'est rien d'autre que l'encapsulation de l'interface
Depuis la fiche principale, je n'ai accès qu'à IPedroTest. Donc on en revient au même problème: Comment libérer correctement l'interface? A moins que je ne comprenne pas ce que tu me dises

Par précaution, les mêmes conventions d'appel sont utilisé?

Oui StdCall partout.

[pepi22]

Pour utiliser l'interface, il faut nécessairement que vous ayez créé l'objet

du genre:

Code :

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

1
2
3
4
5
 
var
  intf :TPedroInterface
begin
intf := TTest.Create;

[Pedro]

Mon dieu... J'ai vraiment honte Le problème de fermeture venait simplement... d'un oubli de StdCall dans leur implémentation dans la DLL Vraiment mille excuses...

En revanche, le problème du bouton sur la barre des tâches reste toujours d'actualité: Soit je passe le Handle de l'application et je n'ai plus de bouton pour la fiche mais le bouton de l'application principale n'est pas enfoncé... Un peu comme si ça ne faisait pas partie de la même application.

[pepi22]

Passer le Handle de Application + affecter la fenêtre principale comme Owner à la création de la fenêtre dans la dll ne règle pas le problème?

[Pedro]

Passer le Handle de Application + affecter la fenêtre principale comme Owner à la création de la fenêtre dans la dll ne règle pas le problème?

Non même souci. Par contre, si on ne passe pas l'application comme Owner dans le Create de la Form, on ne peut pas utiliser Release... Free marche très bien

[pepi22]

Alors là, plus d'idée ... Désolé

[Pedro]

Alors là, plus d'idée ... Désolé

Pas de souci, tu m'as bien aidé Merci!

[Franck SORIANO]

Trouvé

Liens : http://laurent-dardenne.developpez.c...hi/Interfaces/

Dans l'exemple que tu mentionnes, l'interface en question faisait référence à un objet qui n'implémentait pas le comptage de référence. Il dérivait directement de TObject et non pas de TInterfacedObject.

TInterfacedObject est justement définie pour gérer le comptage de référence. Dans ce cas, l'instance se détruit belle et bien toute seule lorsque qu'elle n'est plus référencée.
La libération de l'objet doit donc bien s'effectuer en affectant l'interface à NIL.

Mon dieu... J'ai vraiment honte Le problème de fermeture venait simplement... d'un oubli de StdCall dans leur implémentation dans la DLL

C'est ce que j'allais te dire. Il manque le stdcall sur la procédure qui est exportée. Mais je vois que tu as trouvé tout seul entre temps !
Par contre, je ne comprend pas le problème du bouton. En passant le handle de l'application, tout m'a l'air de fonctioner correctement !

[Franck SORIANO]

Si ça y est j'ai compris quel est le problème.
En fait, j'avais appliqué d'office ma solution habituelle lorsque je met des Form dans une DLL :
- Compile l'appli et la DLL en utilisant les packets d'exécutions.

Au minimum : VCL et Rtl ça doit suffir. De cette façon, l'appli et la DLL partagent directement le même objet Application. Il n'est plus nécessaire de passer le handle de l'appli à la DLL, les deux utilisent le même objet.

[Pedro]

Si ça y est j'ai compris quel est le problème.
En fait, j'avais appliqué d'office ma solution habituelle lorsque je met des Form dans une DLL :
- Compile l'appli et la DLL en utilisant les packets d'exécutions.

Au minimum : VCL et Rtl ça doit suffir. De cette façon, l'appli et la DLL partagent directement le même objet Application. Il n'est plus nécessaire de passer le handle de l'appli à la DLL, les deux utilisent le même objet.

Salut Franck et merci pour ta réponse
Mmmm... Si cette solution fonctionne, elle ne me plait pas trop Ca m'embête de devoir déployer toutes les bpl avec le prog... Je cherche une méthode qui évite ceci.

[Franck SORIANO]

Pas tous, juste 2. Tu vas déployer l'appli, ainsi que les DLL des plugins. Alors déployer 2 dll de plus (les bpl), ça ne change pas grand chose...
Mais c'est vrai que ce n'est pas génial.

Cependant, faire des forms dans des DLL ce n'est pas génial non plus, le code de la VCL est dupliqué dans chaque DLL, ça donne des DLL énormes à chaque fois...

Tu faisais comment sans les interfaces ? Parce que le problème devait être le même avant.

Enfin dernière remarque. Personnellement je n'utiliserais pas les interfaces de cette manière. Cette solution n'est pas vraiment différente de ce que tu ferais sans les interfaces.
Les interfaces sont intéressantes si elles permettent d'écrire les plugins sans avoir besoin d'importer manuellement les fonctions exportées dans les DLL. Ainsi que si elles permettent au plugin d'appeler les services implémentés dans l'application hôte.

Pour faire ce genre de chose, j'irais jusqu'au bout : Faire des objets COM. Dans l'appli hôte, tu crées une bibliothèque de types qui décrit les interfaces que les plugins devront implémenter. De cette façon, ces interfaces seront publiées dans la base de registre. On pourra écrire un plugin en important cette TLB et récupérer automatiquement la définition des interfaces.

Ensuite, chaque plugin est un objet COM qui implémente ces interfaces standards. Lorsque ton appli veut faire appel à un plugin : Tu instancies simplement l'objet COM...

Autre chose, tu devrais faire des interfaces compatibles Ole Automation. De cette façon, ça ouvrira d'autres langages que Delphi et C++ pour l'écriture des plugins.

Bon ça ne résoudra pas le problème du bouton pour autant.

[Paul TOTH]

le problème vient de ce que tu passes des objets Delphi de l'EXE vers la DLL...c'est très mal

sinon le chapitre 19 du livre "Delphi 7 Studio" qui traite justement de ce sujet est disponible en ligne

[Pedro]

Salut Franck

Pas tous, juste 2. Tu vas déployer l'appli, ainsi que les DLL des plugins. Alors déployer 2 dll de plus (les bpl), ça ne change pas grand chose...
Mais c'est vrai que ce n'est pas génial.

Ouais comme tu dis

Cependant, faire des forms dans des DLL ce n'est pas génial non plus, le code de la VCL est dupliqué dans chaque DLL, ça donne des DLL énormes à chaque fois...

Je sais C'est d'ailleurs pour ça que j'essaie de passer par des interfaces.

Tu faisais comment sans les interfaces ? Parce que le problème devait être le même avant.

A la barbare: J'exporte une procédure dans la DLL dans laquelle je passe tous les paramètres dont j'ai besoin (classes et variables). Et la fiche se crée à l'intérieur de cette procédure.

Pour faire ce genre de chose, j'irais jusqu'au bout : Faire des objets COM. Dans l'appli hôte, tu crées une bibliothèque de types qui décrit les interfaces que les plugins devront implémenter. De cette façon, ces interfaces seront publiées dans la base de registre. On pourra écrire un plugin en important cette TLB et récupérer automatiquement la définition des interfaces.

Ensuite, chaque plugin est un objet COM qui implémente ces interfaces standards. Lorsque ton appli veut faire appel à un plugin : Tu instancies simplement l'objet COM...

Malheureusement, ça dépasse mes compétences... De plus, vu l'utilisation que j'en fais, je ne pense pas que le jeu en vaille la chandelle...

Autre chose, tu devrais faire des interfaces compatibles Ole Automation. De cette façon, ça ouvrira d'autres langages que Delphi et C++ pour l'écriture des plugins.

Là, y aura pas de souci tant que Delphi vivra C'est moi qui développe ce prog pour mon bureau

Bon ça ne résoudra pas le problème du bouton pour autant.

le problème vient de ce que tu passes des objets Delphi de l'EXE vers la DLL...c'est très mal

Salut Paul
C'est exactement ce que je disais

sinon le chapitre 19 du livre "Delphi 7 Studio" qui traite justement de ce sujet est disponible en ligne

Tu vas rire, il est, depuis hier, ouvert juste à coté de moi sur ce chapitre Malheureusement, il ne traite pas des plugins qui affichent des contrôles Ou alors j'ai mal cherché

Du coup, je ne sais plus trop quoi faire La plupart des DLL ont seulement 2 fonctions exportées:

• La fonction qui récupère les informations du plugins (Nom, Hint, Caption, Icone, etc.)
• La fonction qui exécute le plugin: création de la fiche, passage de plusieurs classes en paramètre (pour les données et l'interface) Renvoie True ou False suivant ModalResult.

Quelle est la meilleure solution ? Utiliser des packages?
Que je sache au moins pour ce cas de figure minimum car, bien entendu, il y a certaines variantes.

Merci pour vos réponses en tout cas

[Paul TOTH]

Salut Paul
C'est exactement ce que je disais

Tu vas rire, il est, depuis hier, ouvert juste à coté de moi sur ce chapitre Malheureusement, il ne traite pas des plugins qui affichent des contrôles Ou alors j'ai mal cherché

Si tu veux que ton plugin affiche un contrôle avec comme parent un contrôle de ton application, il faut lui passer le Handle du parent et s'en service dans le constructor CreateParented()

Ou alors tu fais en sorte que ton plugin n'ai pas besoin d'un contrôle. Il peux cependant réagir aux événéments OnClick, OnPaint (avec le Handle du Canvas et non le canvas lui même), etc...

De façon générale la propriété Handle fait référence à un objet Windows (HBitmap, HDC, HWnd...), que tu peux utiliser des deux côté. Alors que les instances des objets de la VCL sont liés à l'exe ou à la DLL qui les manipule.

[Pedro]

Merci pour vos réponses

Si tu veux que ton plugin affiche un contrôle avec comme parent un contrôle de ton application, il faut lui passer le Handle du parent et s'en service dans le constructor CreateParented()

Ah j'avais réussi pour un TFrame mais sans utiliser CreateParented. Je vais essayer pour voir si c'est mieux

Par contre, si le plugin n'est qu'un TFrame contenant tous les contrôles à afficher et que l'exécution du plugin dans l'application se contente de créer une TForm vide et d'insérer dedans le TFrame. Est-ce que ce serait mieux ou c'est exactement la même chose? Comprendre: est-ce qu'on s'affranchit des problèmes liés aux TForm depuis des DLL?
Autre proposition: Serait plus propre d'utiliser des packages contenant des TForm (ou autre) ?

Ou alors tu fais en sorte que ton plugin n'ai pas besoin d'un contrôle. Il peux cependant réagir aux événéments OnClick, OnPaint (avec le Handle du Canvas et non le canvas lui même), etc...

Malheureusement, je ne peux pas: chaque plugin a une IHM différente. Tout l'intérêt de ces plugins est d'avoir sa propre interface.

De façon générale la propriété Handle fait référence à un objet Windows (HBitmap, HDC, HWnd...), que tu peux utiliser des deux côté. Alors que les instances des objets de la VCL sont liés à l'exe ou à la DLL qui les manipule.

Je ne peux pas non plus me limiter aux Handle: les paramètres sont obligatoirement des TComponent ("hauteur de hiérarchie" maximum) donc pas de Handle...

N'y a-t-il vraiment aucun moyen d'utiliser des TForm proprement depuis des DLL?

[Paul TOTH]

Si tu veux découper ton projet en modules tout en travaillant avec des instances objets, tu dois passer par les paquets.

Si tu veux avoir une DLL qui fonctionne correctement sans dépendre de la version de Delphi ni du langage (c'est à dire faire une DLL en C par exemple), tu dois passer par des Interfaces.

Dans ce second cas, tu as un peu de boulot pour mettre les choses en place, et ensuite c'est tout facile

exemple

Code :

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

1
2
3
4
5
6
7
8
9
 
type
  IForm = Interface
   function Handle:HWnd;
   function GetWidth: Integer;
   procedure SetWidth(Value: Integer);
   ...
   property Width:Integer read GetWidth write SetWidth;
  end;

si tu associes cette interface à une fiche de ton EXE, tu peux la passer sans problème à la DLL qui en fera ce qu'elle veux en toute sécurité

L'interface est un contrat entre l'EXE et le DLL, peu importe si tu changes de version de Delphi, si TForm évolue d'une version à l'autre, ou si ta DLL est écrite en C, C++ ou ce que tu veux, le contrat reste le même : une interface qui donne un HWnd, une largeur, etc...

[Pedro]

Merci pour ta réponse

Si tu veux découper ton projet en modules tout en travaillant avec des instances objets, tu dois passer par les paquets.

Mes tests n'ont pas été très fructueux jusqu'à maintenant avec les paquets malheureusement. Impossible de récupérer une TForm ou un TPanel. Ca ne marche tellement pas que ça doit forcément venir de mon code... Je continue mes tests.

Si tu veux avoir une DLL qui fonctionne correctement sans dépendre de la version de Delphi ni du langage (c'est à dire faire une DLL en C par exemple), tu dois passer par des Interfaces.

Bah ça pourrait être intéressant seulement pour moi, par envie d'apprendre mais dans l'absolu, c'est inutile!

Dans ce second cas, tu as un peu de boulot pour mettre les choses en place, et ensuite c'est tout facile

exemple

Code :

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

1
2
3
4
5
6
7
8
9
 
type
  IForm = Interface
   function Handle:HWnd;
   function GetWidth: Integer;
   procedure SetWidth(Value: Integer);
   ...
   property Width:Integer read GetWidth write SetWidth;
  end;

si tu associes cette interface à une fiche de ton EXE, tu peux la passer sans problème à la DLL qui en fera ce qu'elle veux en toute sécurité

L'interface est un contrat entre l'EXE et le DLL, peu importe si tu changes de version de Delphi, si TForm évolue d'une version à l'autre, ou si ta DLL est écrite en C, C++ ou ce que tu veux, le contrat reste le même : une interface qui donne un HWnd, une largeur, etc...

Certes, c'est d'ailleurs ce que j'ai déjà fait plus ou moins.

En revanche, cette méthode implique, si on veut une Form par plugin, de créer une Form depuis le programme et insérer un TFrame (par commodité de développement) que la DLL crée. Ca fait un peu bricolage non?
Ceci dit, ta méthode de ne passer que dans Handle me plait assez. Par contre, je ne pourrai pas TOUT faire qu'avec les handles comme tu as pu le voir J'ai des impératifs qui m'en empêche.