Problème avec un "if MaClass is TClass"

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

Code:

---

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:

---

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...

As-tu essayé avec InheritsFrom ?

Code:

---

if objet.InheritsFrom( TC ) then

---

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

Salut,
Egalement un autre piste:

Code:

---

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

---

Citation:

---

Envoyé par TicTacToe

Salut,
Egalement un autre piste:

Code:

---

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

---

---

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

Citation:

---

Envoyé par wezzar

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:

---

1 2 3 4 5

function maFonction(objet : TA) : Boolean; begin if objet.ClassType = TC then [...] end;

---

devient

Code:

---

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 ...

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

Citation:

---

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

---

?

Citation:

---

Envoyé par 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
?

---

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

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:

---

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:

---

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:

---

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;

---

Citation:

---

Envoyé par Paul TOTH

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

---

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 ... :mouarf:

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 !

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 ?

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 ???

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 ?

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

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

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 ...

Citation:

---

Envoyé par sjrd

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

---

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

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 ?

Citation:

---

Envoyé par wezzar

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

---

oups :)

Citation:

---

Envoyé par wezzar

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 !