Discussion :

[joc02]

Bonjour,


Je sais que ce sujet a déjà été discuté plusieurs fois, mais je vous avoue qu'à force de travailler dessus je m'y perds.
Dans mon cas je souhaiterais travailler avec des instances de classes (objets) dans une dll.
Mon exe va créer l'instance le passer à une dll qui va faire un traitement.


Je travaille avec ShareMem pour la mémoire.


Les essais basics sont concluants, par contre dès que j'utilise l'opérateur "IS" le test renvoie en permanence "False".
Je pense avoir trouvé pourquoi, mais cela me pose problème, d'après mes recherches ça serait une histoire d'instance, la VCL aurait 2 instances, une pour l'exe une autre pour la DLL.

Par exemple

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
25
 
library Dll;
 
 
uses
//   FastMM4,
  System.Classes,
  Vcl.Dialogs,
  Vcl.Forms;
 
 
{$R *.res}
 
 
procedure Complex(L : TObject);stdcall;
begin
   if L is TForm then
      showmessage('Ok')
   else
      showmessage('Pas ok') ;
end;
 
 
exports      
      Complex;

Et l'appel

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
 
procedure TffsIsOperator.Button2Click(Sender: TObject);
var
   MaDLL : THandle;
   Proc  : procedure (l : TObject);
begin
   try
      MaDLL := LoadLibrary(PChar('Dll.dll'));
      @Proc := GetProcAddress(MaDLL, 'Complex');
 
 
      Proc(self);
   finally
      FreeLibrary(MaDLL);
   end;
end;

[ShaiLeTroll]

ShareMem ne suffit pas, il faut un BPL

Il compile dans l'EXE tes classes, leur donne une adresse mémoire (RTTI...)
Il compile dans la DLL tes classes, idem RTTI mais comme les uses et peut-être même la nature même d'une DLL fait que ces adresses sont différentes
Le IS utilise les rtti, il voit que le pointeur de classe n'est pas le même, il renvoie False

En mode BPL
il compile le BPL, celui contient ses RTTI de ses classes (et une table d'exporation des classes présentes dans le package)
Il compile l'exe, les classes de l'exe auront leur RTTI dans l'exe, toutes classes présentes dans un BPL auront leur RTTI dans le BPL
le compile la DLL, la classe de la DLL avec RTTI dans la DLL et les classes de la BPL ...
Ainsi la DLL et l'exe partagent les RTTI du BPL, du coup, le IS fonctionne !

L'erreur classique est "Le type TFont n'est pas compatible avec TFont' lorsque l'on joue avec une TForm entre EXE et DLL sans utiliser de BPL


Sans BPL, il te faut faire une fonction GetClass dans la DLL qui fourni la classe de la DLL
Un peu comme le ferait le GetClass du COM

Tu as du surement lire Comment partager un objet entre un exécutable (.exe) et une DLL? ?!

Voir le GetButtonClass dans DLL String Pourquoi ça marche sans BORLNDMM.DLL

[joc02]

Merci pour ces précisions.

Par contre quand vous dites "En mode BPL" vous parlez de la case à cocher "Lier les packages d'exécution".

Si c'est le cas, je m'étais déjà aperçu de l'amélioration avec l'opérateur "IS". Par contre sur certains forums des développeurs déconseillent cette solution. Ils estiment qu'avec les packages d'exécution l'application est moins stable et des memory leak apparaissent.

De plus sur de gros projets je me suis confronté à de nombreuses erreurs (liés surement à mon manque de connaissance) : genre "Package 'indy' requis non trouvé", ....

[ShaiLeTroll]

Par contre quand vous dites "En mode BPL" vous parlez de la case à cocher "Lier les packages d'exécution".....

C'est exactement cela, généré ses propres BPL, les inclure ainsi que ceux fournis par Delphi dans un programme d'Installation (InstallShield, InstallAware...)

Si c'est le cas, je m'étais déjà aperçu de l'amélioration avec l'opérateur "IS".
Par contre sur certains forums des développeurs déconseillent cette solution. Ils estiment qu'avec les packages d'exécution l'application est moins stable et des memory leak apparaissent.

Delphi étant entièrement en mode BPL et en plus gère des BPL en DesignTime (cela change la palette, les component editor, ...)
Vu la richesse de l'IDE, perso, je trouve cela assez stable !

le mode BPL prend aussi beaucoup moins de place en déploiement
Pour avoir maintenu un projet avec 40exe et 80DLL, 3 BPL maisons, cela passe juste chaque binaire de 8-16Mo à 1-3Mo, ce qui donne 960-1920Mo à 120Mo à 360Mo !
Au passage en XE2, tout à grossi de 20% par rapport à 2007
Aujourd'hui, ce n'est pas un problème mais cela peut aussi impacter le chargement,
genre 10 DLL au démarrage, tu lis 150Mo contre 20Mo en mode BPL, c'est toujours ça de gagner

De plus sur de gros projets je me suis confronté à de nombreuses erreurs (liés surement à mon manque de connaissance) : genre "Package 'indy' requis non trouvé", ....

C'est juste un problème de déploiement, il faut savoir gérer sa liste de BPL dans le projet mais aussi dans l'install shield !

[Paul TOTH]

le principal problème des BPL c'est qu'ils sont complètement dépendant de la version du compilateur, un BPL pour XE5 ne fonctionnera pas avec un projet XE6, et même sur une version donnée avec un patch tu peux avoir des problèmes.

la solution la plus élégante est alors d'utiliser des Interfaces que les DLL supportent très bien

[joc02]

C'est juste un problème de déploiement, il faut savoir gérer sa liste de BPL dans le projet, mais aussi dans l'install shield !

Justement y a-t-il un utilitaire qui permet de lister les bpl ?
Idem dans les options de compilation, la liste des BPL qu'il y a sous la case à cocher "Lier les packages d'exécution" peut-elle s'actualiser ? Je me suis aperçu (surement lié à une migration de Delphi 7) que ma liste ne correspondait pas du tout à celle que j'ai si je fais un nouveau projet.


Pour ce qui est des interfaces, cela se passe bien pour des classes maison. Certaines DLL exploitent des composants, et c'est là que ça se gâte.

[Paul TOTH]

Justement y a-t-il un utilitaire qui permet de lister les bpl ?
Idem dans les options de compilation, la liste des BPL qu'il y a sous la case à cocher "Lier les packages d'exécution" peut-elle s'actualiser ? Je me suis aperçu (surement lié à une migration de Delphi 7) que ma liste ne correspondait pas du tout à celle que j'ai si je fais un nouveau projet.


Pour ce qui est des interfaces, cela se passe bien pour des classes maison. Certaines DLL exploitent des composants, et c'est là que ça se gâte.

les DLL ne peuvent exploiter QUE des interfaces, jamais des composants au sens TComponent de Delphi, car comme tu le soulignes dans ton message initial même si ShareMem permet de partager un gestionnaire de mémoire, la DLL et l'EXE possèdent leur propre version de la VCL, pour partager du code il faut utiliser des paquets - d'où la nécessité d'avoir exactement la même version du compilateur avec les paquets sinon il y a incompatibilité entre les deux.

Avec des interfaces tu lèves totalement ces problèmes puisqu'il n'est jamais question d'implémentation, la DLL et l'EXE peuvent avoir des codes totalement différents et même utiliser des langages de programmation différents, seule l'interface est normalisée entre les deux.