Discussion :

[SkYsO]

Bonjour à tous,

Je suis en train de me pencher sur l'écriture d'une dll de classe que j'essaye de faire avec l'aide du cours : http://flash-koti.developpez.com/art.../102-dll/#L2-3

Dans ma classe j'ai une variable que j'aimerais mettre public.
Voici un exemple de déclaration de la classe dans ma dll

Code :

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

1
2
3
4
5
6
7
8
9
10
 
type
  MaClasse = classe
    private
      var1 : integer;
      ...
    public 
      Nom : string; 
     procedure Maproc; virtual; stdcall; export;
end;

Ensuite dans mon application principale je remets la définition avec abstract en fin de ligne pour ma procédure. Mais comment faire avec la variable Nom ?

Peut on l'exporter aussi ? et donc ensuite l'apelle dans le programme principale : MaClasse.Nom ?

Si je l'a met en private et que je défini une méthode, je peux récupérer sa valeur mais je voudrais pouvoir y accéder directement

Merci de m'éclaire

A oui, j'utilise FasteShareMem pour les strings et autres.

[Merlin]

Tu n'as pas bien compris l'exemple de l'article, ton code ne peut fonctionner.
Notamment tu ne peux pas "exporter" une méthode à l'intérieur d'une classe, cela n'a pas de sens.
Si ta classe doit rendre visible des comportements ou des attributs, ils doivent être dans la section public.

Mais pour accéder à la classe elle-même, cela n'est pas possible. Les DLL ne sont pas faites pour ça. Il y a donc deux solutions :
- soit utiliser un package Delphi, qui est un format DLL privé de Borland qui lui permet d'exporter des classes car il contient les métadonnées nécessaires.
- soit "ruser" et c'est l'objet de l'article que tu cites.

La ruse est la suivante :

Il faut créer une fonction qui est elle est exportée par la DLL et qui a pour charge de créer une instance de la classe, instance qu'elle retourne à l'appelant. La classe elle-même n'est pas accessible de l'extérieur de la DLL.
La définition de la classe elle même doit être dans une unité à part utilisée par la DLL mais aussi par le programme appelant (sinon il ne peut pas utiliser la classe). Cet aspect ne semble pas clair dans l'article cité d'ailleurs qui, après rapide lecture semble redéclarer la classe dans le programme appelant ce qui serait une erreur à ne pas commettre bien entendu.

[SkYsO]

Salut,

Et bien pourtant je ne pense pas m'être trompé.
J'ai peut être oublié de préciser que j'ai aussi :

Code :

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

1
2
3
4
5
6
7
 
Function CreeInstanceMaClass() : TMaClass; stdcall; export;
 
Function CreeInstanceMaClass : TMaClass;stdcall; export;
begin
  result:=TMaClass.Create;
end;

Je récupere mon objet de cette manière.
Et ensuite je peux appeler ses méthodes public non ?

car j'ai fais le test et ça marche plutôt bien.
Dans mon programme principal j'ai juste la structure de ma Classe mais pas de redéfinition des méthodes.

Par contre je n'arrive pas à accéder aux Attributs public.

[SkYsO]

Pas d'autres idées ?

Personne n'utilise des objets séparés dans d'autres dll ?

;(

[flash]

Bonjour,

Il me semble que c'est normal que tu ne puisse pas accéder au variable même public d'une dll. En gros, ton appli et ta dll ne se partage pas la mémoire. Je dis ça de tête car je n'ai pas touché Delphi depuis des siècles.

Cela dit, il y a une solution a ton problème et en plus c'est dans mon cours . Base toi sur l'exemple de la "calculette". Comme tu le verras on recupère la somme qui est en fait stocké dans un composant Label ce qui rejoint tes attributs.
En effet :

Code :

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

1
2
 
Label3.Caption := FloatToStr(StrToFloat(Edit1.Text) + StrToFloat(Edit2.Text));

Alors que dans l'appli qui utilise la "calculette", on a :

Code :

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

1
2
3
4
 
R := Total;
 
lbResultat.Caption := FloatToStr(R);

Où Total est une fonction qui récupère le caption de Label3.

Sinon, tu peux trés bien intégrer l'unité et la form dans ton application principal. Je veux dire oublier les dll. Dans ce cas, tu crées une instance de l'objet (la form) dans le meme espace mémoire que l'appli et tu peux accéder au attribut de la forme sans autre forme de procés. Alors qu'en Dll, je pense que tu ai obligé de prévoir des fonctions qui manipule les attribut issue de la Dll.

Une piste que tu peux explorer, mais je vais pas pouvoir t'aider, c'est de récupérer le handle de la form créée par la Dll. Car le handle est un pointeur sur l'espace mémoire de la Dll. Donc il est possible de s'adresser directement aux attributs qui sont enfants de la Form. Mais là, il y a du boulot.

Bon Courage

Continue d'utiliser ce sujet du forum pour poser tes questions et éventuellement envoit moi un message privé. Mais je suis pas super dispo et ma machine où je fais le développement est morte

Voilà

Flash Koti
[Balises CODE rajoutées par Pedro. Merci d'y penser à l'avenir]

[SkYsO]

Merci pour ta réponse.

Bon donc je crois que je vais me tapper des set et des Get d'attributs, ce qui n'est pas très grave mais juste un peu plus long.

Je reste dans l'optique d'objet dans une dll car j'en ai besoin pour plusieurs raisons et justement l'ancien fonctionnement était d'avoir les objets directement dans l'application principale.

Et il y avait plein d'attributs publics (ce qui n'est pas forcément une bonne chose).

Pour ton exempe de calculette, je ne sais pas si je peux vraiment m'en inspirer car mon projet se présentera comme ça :

Appli principale :=>Dll de classe.
et même des fois :
Appli principale :=>Dll composants => dll de classe.