Discussion :

[wezzar]

Bonjour,
J'ai 2 classes B et C qui héritent de A.
J'ai une fonction suivante :

Code :

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

1
2
3
4
5
6
 
function maFonction(objet : TA) : Boolean;
begin
   if objet.ClassType = TC then
    [...]
end;

Même si je passe en paramètre une instance de la classe C, il m'évalue toujours la condition à faux. Pire, en mode débeug, object.ClassType est bien égal à TC mais il m'évalue quand même la condition à faux..

J'ai essayé aussi :

Code :

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

1
2
3
4
5
6
 
function maFonction(objet : TA) : Boolean;
begin
   if objet is TC then
    [...]
end;

Ca ne marche pas non plus.

Une explication ? Une idée ?

[Edit] En écrivant ces lignes, je me dis que je devrais faire des overload des fonctions plutôt que des pauvres if...

[Aka Guymelef]

As-tu essayé avec InheritsFrom ?

Code :

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

if objet.InheritsFrom( TC ) then

C'est néanmoins curieux que ça n'ait pas fonctionné avec l'opérateur is.

[TicTacToe]

Salut,
Egalement un autre piste:

Code :

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

if Objet.ClassName = 'TC' then ...

[wezzar]

Salut,
Egalement un autre piste:

Code :

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

if Objet.ClassName = 'TC' then ...

Non, ça c'est très sale !

[ShaiLeTroll]

Bonjour,
[Edit] En écrivant ces lignes, je me dis que je devrais faire des overload des fonctions plutôt que des pauvres if...

Tu veux dire override dans le cadre d'une surcharge d'une méthode ancêtre héritée ... en procédant en méthode objet ... autant utiliser le langage objet tel qu'il existe au lieu de faire du procédural qui n'est pas adapté à la situation (dans d'autres ça peu)

Code :

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

1
2
3
4
5
function maFonction(objet : TA) : Boolean;
begin
   if objet.ClassType = TC then
    [...]
end;

devient

Code :

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

1
2
3
4
5
6
7
8
9
10
function TA.maFonction() : Boolean; // virtual dans le prototype
begin
  ...
end;
 
function TC.maFonction() : Boolean; // override dans le prototype
begin
  inherited maFonction; // n'est pas obligatoire surtout si le comportement est radicalement différent
  ...
end;

En fin, tu n'aurais pas une histoire de DLL ? un objet créé dans l'exe, et transmis à une procédure de DLL ? car effectivement les références de classe sont différentes, il faut soit faire un paquet, soit gérer à la main le partage de classe via un recensement de l'exe vers la DLL et réciproquement ...

[wezzar]

Non non override ne colle pas à ce que je cherche, la fonction "maFonction" ne fait pas partie d'une des classes A, B ou C.
Mais tu as tout à fait raison, "maFonction" se trouve bien dans une DLL et je lui transmet l'instance de de la classe depuis un exe qui fait appel à cette DLL.
Que veux-tu dire par

gérer à la main le partage de classe via un recensement de l'exe vers la DLL et réciproquement

?

[Paul TOTH]

Non non override ne colle pas à ce que je cherche, la fonction "maFonction" ne fait pas partie d'une des classes A, B ou C.
Mais tu as tout à fait raison, "maFonction" se trouve bien dans une DLL et je lui transmet l'instance de de la classe depuis un exe qui fait appel à cette DLL.
Que veux-tu dire par
?

bien vue le Troll, je l'avais pas vue venir celle là

et bien la DLL et l'Exe possèdent chaqu'un une version propre de la classe, donc le test ne sera jamais vrai.

imagine ce que ça donnerait si tu mettais à jour la classe TC dans la DLL sans recompiler l'exe.

Delphi ne supporte pas comme le C++ les déclarations de classes externes. Pour moi le seul moyen de gérer les choses proprement est de masquer la nature de la classe en créant un jeu de fonctions manipulant un THandle générique :

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
 
library exemple;
 
function CreateMonObject:TMonObject;
begin
 Result:=TMonObject.Create;
end;
 
procedure DestroyMonObject(obj:TMonObject);
begin
 obj.Free;
end;
 
procedure MethodeObject(obj:TMobjObject);
begin
 obj.Methode;
end;
exports
 CreateMonObject,
 DestroyMonObject,
 MethodeObject;

et côté EXE

Code :

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

1
2
3
4
 
function CreateMonObject:THandle; external 'exemple.dll';
procedure DestroyMonObject(obj:THandle); external 'exemple.dll';
procedure MethodeObject(obj:Thandle); external 'exemple.dll';

tu peux éventuellement créer une classe aussi dans l'exe

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
 
type
 TMonObject=class
 private
  fHandle:THandle;
 public
  constructor Create;
  destructor Destroy; override;
  procedure Methode;
 end;
 
constructor TMonObject.Create;
begin
 fHandle:=CreateObject;
end;
 
destructor TMonObject.Destroy;
begin
 DestroyObject(fHandle);
end;
 
procedure TMonObject.Methode;
begin
 MethodeObject(fHandle);
end;

[ShaiLeTroll]

bien vue le Troll, je l'avais pas vue venir celle là

Merci, mais depuis mon sujet "DLL String Pourquoi ça marche sans BORLNDMM.DLL", ce genre de problème, je le pige vite, et le fait de faire une function non objet m'as mis la puce à l'oreille ...

Sinon pour le recensement des classes de l'exe vers la DLL et réciproquement, en fait, il faudrait faire une fonction dans la DLL genre de RegisterClass ... consulte le lien que j'ai fourni, en particulier GetButtonClass, qui te donne un idée d'un register automatique des classes entre l'exe et la DLL

Sinon, j'insiste les Paquets d'Execution, c'est la solution pour que la DLL et EXE partage les mêmes classes ! il y a un tutoriel dessus !

[wezzar]

Je viens de créer un paquet d'exécution contenant mes classes A, B et C.
Je fais en sorte que mon programme et ma DLL utilisent ce paquet (options -> Packages), mais j'obtiens le même problème...
J'ai bien vérifié les unitées déclarées pointent bien vers le paquet d'exécution.
Une idée ?

[ShaiLeTroll]

Tu as bien coché la case "Construire avec les paquets d'exécution" et mis les Classes A, B et C dans un paquet (Projet .DPK donnant un .BPL), et ajouter ce paquet dans la liste ???

[wezzar]

Effectivement avec cette case ça marche, mais ça m'embête énormément de devoir redistribuer les paquets séparément. Il n'y a pas un moyen d'associer juste le paquet de mes classes ?

[ShaiLeTroll]

Tu as d'autres solutions :
- L'encapsulation proposée par Paul Toth
- Le Recensement que j'ai proposé
...

[sjrd]

Il y a aussi l'usage d'interfaces, mais c'est une autre histoire

[ShaiLeTroll]

Effectivement SJRD, les interfaces utilisent d'ailleurs un principe de recensement via les CLASS ID ... avant d'en arriver à de tel moyen (le meilleur mais pas forcément le plus simple pour les novices), autant qu'il essaye d'autre méthode qui lui apprendront en plus quelques bases qui lui serviront à comprendre l'objet, les pointeurs, ... qu'il faut connaitre avec de s'attaquer aux Interfaces ...

[Paul TOTH]

Il y a aussi l'usage d'interfaces, mais c'est une autre histoire

oui c'est pas faux d'ailleurs le chapitre 19 de "Delphi 7 Studio" sur les DLL est en ligne chez Eyrolles

[wezzar]

J'avais pas bien compris ta section sur les Interfaces dans ton livre Paul, mais après relecture je vais essayer cette option.

Et si j'ai bien compris, le fait que les objets ne soient pas géré de la même manière avec une DLL qu'un programme vient du fait que la structure de celles-ci a été définie avant la programmation objet et n'a pas évolué depuis ?

[Paul TOTH]

J'avais pas bien compris ta section sur les Interfaces dans ton livre Paul, mais après relecture je vais essayer cette option.

oups

Et si j'ai bien compris, le fait que les objets ne soient pas géré de la même manière avec une DLL qu'un programme vient du fait que la structure de celles-ci a été définie avant la programmation objet et n'a pas évolué depuis ?

ben c'est surtout que ce n'est pas simple de placer un objet dans une DLL. En C++ on a un fonctionnement un peu batard qui permet de le faire, le mappage de l'objet entre la DLL et l'EXE est fait automatiquement, mais tu peux aussi avoir une partie du code dans l'EXE puisque le .h peux très bien contenir du code (d'où la difficulté pour intégrer une DLL object C++ dans Delphi).

l'avantage des interfaces c'est que se sont juste des tableaux de méthodes (des pointeurs donc) et que c'est parfaitement défini. Attention cependant, il ne faut pas venir coller des types dynamiques dans l'interface ! (string, tableaux dynamiques, etc..) car tu retombes sur les mêmes problèmes que précédemment sur la gestion mémoire !