Discussion :

[ChPr]

Bonjour à toutes et à tous,

Continuant sur mon projet, je tombe sur un nouvel os.

Les échanges avec mes DLL fonctionne bien, mais dans certaines, j'ouvre une fenêtre de dialogue. Pour ce faire, dans l'initialisation de la fiche je place l'instruction :

Code :

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

1
2
initialization
  MaFiche:= TMaFiche.Create(Application);

et dans le corps de ma DLL je fais un

Code :

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

MaFiche.ShoModal;

Cela fonctionnait à merveille dans ma version DELPHI 6, cela fonctionne dans ma version Lazarus sous Ubuntu 11.04, mais refuse de fonctionner sous WIndows XP : il n'y a pas de plantage, mais la fenêtre refuse obstinément de s'afficher.

Si je remplace l'instruction d'initialisation par :

Code :

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

Application.CreateForm(TMaFiche, MaFiche);

ça plante,

Si je mets cette instruction entre le begin et le end de l'unité "Library", ça plante aussi.

Bref, je ne sais plus quoi faire.

Si vous avez des idées.

Je vous en remercie par avance.

Pïerre

[tourlourou]

si tu gères toi-même la création/destruction des fiches, ne vaut-il pas mieux passer nil que Application comme Owner ?

sinon, il y a peut-être problème lié à l'ordre des initialisations ?

solution bâtarde à tester : faire dans l'appli une CallBack qui encapsule le ShowModal, et sera appelée par la librairie

[ChPr]

si tu gères toi-même la création/destruction des fiches, ne vaut-il pas mieux passer nil que Application comme Owner ? ...

J'avais déjà essayé, pas mieux.

... sinon, il y a peut-être problème lié à l'ordre des initialisations ? ...

J'avais aussi essayé à différents endroits dont juste avant l'appel à ShowModal : pas mieux.

... solution bâtarde à tester : faire dans l'appli une CallBack qui encapsule le ShowModal, et sera appelée par la librairie

Je ne sais pas faire !

NOTA : du fait que cela fonctionnait avec DELPHI, que cela fonctionne avec Lazarus sous Linux, peut-on considérer le dysfonctionnement sous Windows comme un bug ?

Merci de votre aide.

Pierre

[tourlourou]

une question bête : se passe-t-il qqch de particulier dans le OnShow ou le OnActivate ?

sinon, pour une fiche Form2 crée par la fiche principale de l'appli, son Form2.ShowModal dans la fiche principale se passe-t-il bien ?

si c'est le cas, l'idée de la CallBack est de passer une fonction à la librairie :
dans la librairie. schématiquement :

Code :

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

1
2
3
4
5
6
7
8
var
  LibShowForm: TMyShowFunction;
 
exports LibShowForm; // on peut exporter des variables
 
begin
  i:=LibShowForm; // appellera la fonction de la fiche principale
end;

dans la fiche principale :

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
type
  TMyShowFunction: function(): integer;
 
function MyShowModal: integer;
begin
  Form2.ShowModal;
  Result:=Form2.ModalResult;
end;
 
begin
  // je ne sais pas de tête comment récupérer une variable exportée d'une dll, mais je pense que c'est aussi avec 
  VarLib:=GetProcAddress(H, 'LibShowForm');
  // puis on lui affecte la procédure de la fiche principale 
  VarLib:=MyShowModal; // ou @MyShowModal en FPC !
end;

[ChPr]

une question bête : se passe-t-il qqch de particulier dans le OnShow ou le OnActivate ?

Rien, aucun des deux évènements n'est appelé, ça plante avant.

... sinon, pour une fiche Form2 crée par la fiche principale de l'appli, son Form2.ShowModal dans la fiche principale se passe-t-il bien ? ...

Une Form2 dans l'appli principale, qu'elle soit créée automatiquement ou bien par un Form2:= TForm2.Create(Application) dans la clause initialization de la fiche de Form2 s'affiche sans problème à l'appel de Form2.ShoModal.

... si c'est le cas, l'idée de la CallBack est de passer une fonction à la librairie :

Je n'ai rien compris. A qui appartient la Form2 dans ton exemple ? A l'appli principale ou à la DLL ?

Merci de votre aide.

Pierre

[tourlourou]

l'idée de la callback est de faire exécuter le code du côté qui le peut, qui fonctionne, ou bien où c'est le plus facile.

tu as confirmé qu'une Form2 créée et appelée en ShowModal par Form1 (fiche principale) ne pose pas de problème.

du côté Form1 (fiche principale), tu auras donc toute la "mécanique"
qui gère le ShowModal de la Form2 dans une fonction qui sera appelée depuis la librairie (finalement, on exporte vers la dll une fonction de l'appli : c'est un juste retour des choses...)

c'est pê plus clair dans ma tête que dans ma prose !

[ChPr]

l'idée de la callback est de faire exécuter le code du côté qui le peut, qui fonctionne, ou bien où c'est le plus facile ...

Ça, j'ai compris.

... tu as confirmé qu'une Form2 créée et appelée en ShowModal par Form1 (fiche principale) ne pose pas de problème. ...

La form2 dont je parle appartenait à l'appli, pas à la DLL

... du côté Form1 (fiche principale), tu auras donc toute la "mécanique" qui gère le ShowModal de la Form2 dans une fonction qui sera appelée depuis la librairie (finalement, on exporte vers la dll une fonction de l'appli

La Form2 dont tu parles ici appartient à qui ? à la DLL ou à l'appli ?

Cordialement.

Pierre

[ChPr]

J'ai procédé de la manière suivante :

J'ai défini une fonction d'échange :

Code :

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

1
2
3
4
TLinkDLL = procedure (var F: TForm); stdcall;
 
var
LinkDLL: TLinkDLL;

dans l'appli je l'appelle comme suit :

Code :

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

1
2
3
4
5
6
7
procedure appel;
var
  FD: TForm;
begin
  LinkDLL(FD); {Appel de la procédure dans la DLL et récupération de la fiche : OK}
  FD.ShowModal; {Affichage de la fiche : plantage !}
end;

dans la DLL :

Code :

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

1
2
3
4
5
6
7
8
9
10
procedure LinkDLL(var FDLL: TForm); stdcall;
begin
  FDLL:= Form1; {Transfert de Form1 dans la variable FDLL : OK}
end;
 
{ TForm1 }
 
initialization
  Form1:= TForm1.Create(Application); {Création de la Fiche: OK}
end.

A moins que mon code soit foireux : ça plante toujours;

Dans le principe, cela ne m'étonne pas car, si la "mécanique" fonctionne, elle s'applique à des variables (celles de la DLL) où il y a problème.

NOTA : ce code fonctionne sous Linux !

Merci de votre aide.

Pierre

[ChPr]

J'ai fait un rapport sur le bugtracker de Lazarus.

Cordialement.

Pierre

[Ph. B.]

Bonjour,
J'ai suivi la discussion. J'ai pris un peu de temps pour réaliser un test (sous windows XP avec Delphi 7 et Lazarus 0.9.30/FPC 2.4.2). J'ai joint un zip avec les différents sources.
Voici mes résultats :
Une dll sous D7 et un exe sous D7 : RAS, tout fonctionne
Une dll sous D7 et une exe sous Lazarus : : RAS, tout fonctionne
Une dll sous Lazarus et un exe sous D7 : violation d'accès dès que l'on appelle une instruction lié à l'affichage (showmessage, showmodal, etc), les autres appels fonctionnent.
Une dll sous Lazarus et une exe sous Lazarus : exception External SIGSEGV dès que l'on appelle une instruction lié à l'affichage (showmessage, showmodal, etc), les autres appels fonctionnent.
Il y a donc un bug (sous windows du moins) sur la gestion de tout ce qui est lié à l'affichage...
Si les sources peuvent aider au bug tracker de Lazarus...
--
Philippe.

[alanglet]

Bonjour,

Il me semble qu'il s'agit là d'un "vieux" problème qui traine depuis des années, déjà signalé en 2006 http://bugs.freepascal.org/view.php?id=1866
Je crois même qu'une prime a été proposée à celui qui le résoudrait http://wiki.lazarus.freepascal.org/B...37182_-_.24100

André

[ChPr]

Bon, ben c'est mal parti cette histoire .

Cordialement.

Pierre

[ChPr]

J'ai fait d'autres test avec les librairies et j'ai eu des problèmes avec les composants TListBox ou TComboBox: voir le rapport que j'ai fait, et surtout la réponse qui m'a été faite :

"Using the LCL in a DLL is still considered an unimplemented/unsupported feature."

.

Cordialement.

Pierre

[Paul TOTH]

ton code est foireux, il peut éventuellement fonctionner si l'exe et la dll sont compilés avec la même version du compilateur, mais là encore tu risques des problèmes.

en effet ta DLL crée un TForm avec une structure propre à la version du compilateur de la DLL, ce pointeur est retourné à l'EXE qui va le manipuler comme si c'était "sa" version de TForm définie par son compilateur.

si tu invoques une méthode virtuelle de TForm - ET que la DLL et l'EXE déclarent TForm exactement de la même façon - ET que Delphi et FreePascal organisent la VMT de la même façon (ça fait déjà beaucoup de "si"), l'EXE va invoquer la méthode codée dans la DLL via le pointeur présent dans la VMT et ça fonctionnera.

si tu invoques une méthode statique, c'est la version de l'EXE qui sera invoquée et qui tentera de manipuler des données appartenant à la DLL (ça peut éventuellement fonctionner avec ShareMem afin de partager le gestionnaire de mémoire).

La seule chose "orienté object" que tu peux partager entre un EXE et une DLL sans problème c'est une Interface.

si tu veux partager un TForm tu peux déclarer

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
type
  IForm = Interface
    function ShowModal: TModalResult;
  end;
 
  TForm1 = class(TForm, IForm)
  ...
  end;
 
procedure LinkDLL(var Form: IForm);

là, peu importe la version du compilateur, l'objet supportant l'interface IForm clairement définie tu peux la manipuler sans contrainte...mais toujours en tant que IForm (interface à compléter avec tout ce dont tu as besoin).

Note que tant que IForm ne fait que regrouper des fonctions de TForm, tu n'as rien à coder de particulier...mais l'objet contiendra une table de méthodes (une interface donc) qui sera traitée de la même façon par l'EXE et la DLL...c'est l'équivalant d'une liste de méthodes virtuelles.

[ChPr]

ton code est foireux, il peut éventuellement fonctionner si l'exe et la dll sont compilés avec la même version du compilateur, mais là encore tu risques des problèmes.

en effet ta DLL crée un TForm avec une structure propre à la version du compilateur de la DLL, ce pointeur est retourné à l'EXE qui va le manipuler comme si c'était "sa" version de TForm définie par son compilateur. ...

Ce code foireux ne m'a jamais posé de problème avec DELPHI 6 et, lisant à l'époque la doc de DELPHI, il n'a jamais été fait mention d'utiliser les interfaces pour ce genre de chose.

Par ailleurs, ce que tu dis semble en contradiction avec les essais de "Ph. B." (message #10 de ce fil) ou il teste et dit, entre autres :

Une dll sous D7 et une exe sous Lazarus : : RAS, tout fonctionne

C'est d'ailleurs un peu le sens des librairies : pouvoir être codées dans un autre langage que le programme qui les utilise.

... - ET que Delphi et FreePascal organisent la VMT de la même façon (ça fait déjà beaucoup de "si"), l'EXE va invoquer la méthode codée dans la DLL via le pointeur présent dans la VMT et ça fonctionnera. ...

Je ne vois pas pourquoi tu parles de DELPHI et de FreePascal ici, car je n'utilise que FreePascal dans une seule et même version pour mon programme et mes librairies.

... La seule chose "orienté object" que tu peux partager entre un EXE et une DLL sans problème c'est une Interface.

si tu veux partager un TForm tu peux déclarer

A mon sens, je ne partage pas un TForm, mon programme et mes librairies ont chacun leurs propres TForm. Mais peut-être que je ne comprends pas ce que tu veux dire.

Aussi, j'avoue ne jamais avoir bien compris cette notion d'interface ... que je n'ai jamais utilisée.

Par ailleurs, la réponse des développeurs de FreePascal est quand même claire :

"Using the LCL in a DLL is still considered an unimplemented/unsupported feature."

Ils reconnaissent bien qu'il y a potentiellement problème.

Cordialement.

Pierre

[Ph. B.]

Bonjour,

...Par ailleurs, ce que tu dis semble en contradiction avec les essais de "Ph. B." (message #10 de ce fil) ou il teste et dit, entre autres :

Une dll sous D7 et une exe sous Lazarus : : RAS, tout fonctionne

Juste une précision sur mes tests pour qu'il n'y ait pas d’ambiguïté ni d'incompréhension :

Dans mon test, ma dll exporte de simples procédures ou fonctions avec des arguments de type simples (entier, booléen, caractère mais pas chaine de caractères, cf. l'aide de Delphi sur les type simples). Elle n'exporte pas d'objets (par exemple de type TForm), je ne m'y risquerai certainement pas entre un exécutable et une dll compilé avec 2 versions différentes d'un même outil de développement et encore moins avec 2 outils différents. Si je devais le faire, j'emploierais la même méthode que celle décrite par @Paul Toth.

D'ailleurs, si j'ai 2 minutes, "je m'amuserais" à faire un petit projet pour tester cela du moins entre 2 versions de Delphi...
--
Philippe.

[ChPr]

Bonjour,

Juste une précision sur mes tests pour qu'il n'y ait pas d’ambiguïté ni d'incompréhension :

Lorsque vous dites :

Une dll sous D7 et une exe sous Lazarus : : RAS, tout fonctionne

Qu'est-ce que cela veut dire ?

J'ai chargé votre zip et j'ai compilé sous D6 et Lazarus vos tests. Je retrouve le fonctionnement que vous dites. Notamment avec un exe Lazarus et une DLL DelPHI (6 chez moi).

Dans ce test, à partir de l'exe Lazarus, j'ouvre une fenêtre appartenant à la DLL DELPHI. C'est ce que je cherche à faire avec un exe et une DLL Lazarus qui chez vous comme chez moi ne fonctionne pas.

Je ne sais pas ce que vous appelez "exporter" un TForm et qui a l'air de vous poser problème. Pour moi, le tout est que à partir d'un exe, j'ouvre une fenêtre appartenant à une DLL, ce que vous faites dans vos tests.

J'y ai même rajouté dans chacune d'elles (dans l'exe et dans la DLL) un ComboBox : cela fonctionne.

Cordialement.

Pierre

Cordialement.

Pierre

[Paul TOTH]

Ce code foireux ne m'a jamais posé de problème avec DELPHI 6 et, lisant à l'époque la doc de DELPHI, il n'a jamais été fait mention d'utiliser les interfaces pour ce genre de chose.

Par ailleurs, ce que tu dis semble en contradiction avec les essais de "Ph. B." (message #10 de ce fil) ou il teste et dit, entre autres :

Une dll sous D7 et une exe sous Lazarus : : RAS, tout fonctionne

C'est d'ailleurs un peu le sens des librairies : pouvoir être codées dans un autre langage que le programme qui les utilise.


Je ne vois pas pourquoi tu parles de DELPHI et de FreePascal ici, car je n'utilise que FreePascal dans une seule et même version pour mon programme et mes librairies.

Peu importe, les objets Pascal ne sont pas fait pour être partagés entre DLL et EXE, or c'est ce que tu fais dans ce code;

Code :

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

1
2
3
4
5
6
7
8
 
procedure appel;
var
  FD: TForm;
begin
  LinkDLL(FD); {Appel de la procédure dans la DLL et récupération de la fiche : OK}
  FD.ShowModal; {Affichage de la fiche : plantage !}
end;

A mon sens, je ne partage pas un TForm, mon programme et mes librairies ont chacun leurs propres TForm. Mais peut-être que je ne comprends pas ce que tu veux dire.

Dans le code ci-dessus, l'EXE invoque une méthode d'un TForm qui provient de la DLL...c'est un partage.

Aussi, j'avoue ne jamais avoir bien compris cette notion d'interface ... que je n'ai jamais utilisée.

c'est très simple et très pratique.

tu prends deux objets quelconques, tu veux pouvoir les utiliser de la même façon alors qu'ils n'ont potentiellement aucun ancêtre commun. La solution, c'est d'utiliser une Interface

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
type
  IToString = interface
    function ToString: string; 
  end;
 
  TMonObjet = class(..., IToString)
    function ToString: string; 
  end;
 
  TUnAutreObjet = class(..., IToString)
    function ToString: string;
  end;

et voilà que les objets MonObjet et UnAutreObjet peuvent être utilisés comme un IToSTring alors qu'ils n'ont rien de commun.

Dans ton cas ce sont des TForm identiques en apparence, mais en fait l'exe d'un côté et la dll de l'autre ont leur propre version de TForm, ça fonctionne sous certaines conditions que j'ai évoqué plus haut, mais ce n'est pas fait pour ! en ajoutant une Interface, tu crées un système qui EST partagé entre la DLL et l'EXE, peu importe que ce soit ou pas le même type d'objet, l'Interface est là pour assurer une compatibilité réelle entre les deux. C'est ce qui est utilisé par les objets COM pour permettre à des langages totalement différents de communiquer...mais ça marche tout aussi bien de FreePascal vers FreePascal

Par ailleurs, la réponse des développeurs de FreePascal est quand même claire :

"Using the LCL in a DLL is still considered an unimplemented/unsupported feature."

Ils reconnaissent bien qu'il y a potentiellement problème.

Ils disent comme moi que ce n'est pas fait pour

En résumé, ce n'est pas parce que le code fonctionne dans certains cas qu'il est valide...par exemple tu peux utiliser un objet après sa libération car il est toujours en mémoire, mais tu as toutes les chances de rencontrer des problèmes en faisant cela, même s'il est possible de le faire sans plantage dans certains cas.
Les objets LCL/VCL en sont pas prévus pour le partage DLL/EXE, si tu le fais tu dois avoir une parfaite connaissance de la structure de tes objets et de leur fonctionnement interne pour savoir si ça plantera ou non.

[Ph. B.]

J'ai chargé votre zip et j'ai compilé sous D6 et Lazarus vos tests. Je retrouve le fonctionnement que vous dites. Notamment avec un exe Lazarus et une DLL DelPHI (6 chez moi).

Ben oui car ma dll propose une "simple" procédure pour demander l'affichage de la TForm qu'elle a créée. Ma dll gère tout (de la création à l'affichage), ne propose pas une variable de type TForm à mon exe qui lui appellerait la procédure ShowModal... C'est ce cas qui est dangeureux.

C'est ce que je cherche à faire avec un exe et une DLL Lazarus qui chez vous comme chez moi ne fonctionne pas.

Tout à fait et cela vient de Lazarus qui ne sait pas créer correctement une dll qui intègre des éléments graphiques qui vont être affichés...
Il n'y a pas de solutions de contournement tant que l'équipe de développement de Lazarus ne l'aura pas pleinement appréhendé (car ce n'est pas simple) et corrigé.

Je ne sais pas ce que vous appelez "exporter" un TForm et qui a l'air de vous poser problème.

Créer la TForm dans la dll et retourner la variable TForm à l'exe qui lui en appellera ses différentes méthodes (ShowModal par exemple).

Pour moi, le tout est que à partir d'un exe, j'ouvre une fenêtre appartenant à une DLL, ce que vous faites dans vos tests.

Tant que ta dll ne transmet pas à ton exe des objets pour lesquels il appellera directement les méthodes, cela fonctionnera...
--
Philippe.

[ChPr]

Peu importe, les objets Pascal ne sont pas fait pour être partagés entre DLL et EXE, or c'est ce que tu fais dans ce code;

Code :

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

1
2
3
4
5
6
7
8
 
procedure appel;
var
  FD: TForm;
begin
  LinkDLL(FD); {Appel de la procédure dans la DLL et récupération de la fiche : OK}
  FD.ShowModal; {Affichage de la fiche : plantage !}
end;

Dans le code ci-dessus, l'EXE invoque une méthode d'un TForm qui provient de la DLL...c'est un partage.

Attention : ce code est celui que j'avais mis en oeuvre pour répondre à une question de Tourlourou dans le message #6. Je conçois que cela ne marche pas.

Ce n'est pas ce que je fais normalement. Je n'appelle pas depuis mon exe des fonctions du TForm de ma DLL. Depuis mon exej j'appelle une fonction de la Dll qui elle, appelle les fonctions de son propre TForm. Voir le zip du rapport de bug 20320

Donc, soyons clair : je ne partage pas de fonctions de composants appartenant à la dll et/ou à l'exe. Chacun appelle ses "propres" fonctions.

Dans ces conditions, je ne vois pas l'utilité de l'interface. Ou alors je n'ai strictement rien compris (ce qui est largement possible ).

Cordialement.

Pierre