Delphi 7, procedure d'objet

Hello,

Il m'arrive un truc bête et je vais passer pour un débutant mais tant pis.

Je veux créer une fonction dans une unité, cette fonction utilisant un objet qui nécessite de coder un évènement. Il s'agit du composant TSmtpCli des ICS.
Dans la fonction, je crée mon objet et je peux assigner des valeurs aux propriétés. Pas de problème !
Mais je veux coder l'évènement OnSessionConnected.
Dans un Delphi "d'aujourd'hui", je déclarerai un type "reference to" et je m'en sortirai sans problème. Ou plus simplement avec une fonction anonyme.

Mais dans un vieux Delphi (le 7 en l’occurrence), je ne sais plus faire :-(
Si je fais :

Code:

---

1 2 3 4 5 6 7 8 9

procedure MonOnSessionConnected(Sender: TObject; ErrCode: Word); begin // ............ end;   // puis   FSmtpCli.OnSessionConnected := MonOnSessionConnected;

---

Je ramasse une erreur de types incompatibles. Normal, ma procédure n'est pas une procédure d'objet. Et je ne sais plus comment faire ce genre de chose.

Qui pourrait me sortir de mon ignorance svp ? :-)

Papy

2 solutions

1) créer un objet pour y mettre ta méthode

2) dériver TSMTPCli pour surcharger la méthode qui gère le OnSessionConnected et y mettre ton traitement ou permettre l'appel à une procédure non objet.

Créer un objet supplémentaire, j'y avais pensé mais j'imaginais une solution sans passer par là.

Dériver le composant, j'ai essayé mais j'ai du faire une erreur quelque part.
L’événement est bien déclenché mais le Sender était toujours nil dans le code implémenté.

Je vais regarder ça de plus près aujourd'hui. Je serai mieux réveillé qu'hier soir :)

Merci Paul.

Sinon, j'avais trouvé ça sur Stackoverflow:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

procedure MyClick(Self, Sender: TObject); begin //... end;   var M: TMethod; begin M.Data := nil; M.Code := @MyClick; MyMenuItem.OnClick := TNotifyEvent(M); end;

---

Qu'en penses-tu ? J'ai pas encore testé.

Une déclinaison du principe, au 4-2 de l'article de Laurent Dardenne, avec une fonction MakeProcedureOfObject élégante.

Joli :P

Merci pour ce lien très intéressant !

Personnellement, je préfère encapulser par une autre classe
Au lieu d'utiliser directement TSmtpCli dans le code, j'utilise une classe qui l'encapsule par composition (surtout pas héritage) et n'expose que les parties utiles
Ainsi, demain, tu remplace TSmtpCli par TIdSmtp, sans devoir retoucher tous les codes appelants !

Par expérience avec Indy qui change régulièrement, c'est la plaie de se taper tous les prototypes qui ont changés !

Comme tu as encapsulé, tu as une classe et donc tu peux fournir un Event Handler

La technique du TMethod comme trouvé sur Stackoverflow ou presenté par Laurent Dardenne est possible, c'est juste dommage de ne pas profiter de la OO en repassant en procédurale !
En général, le retour procédurale te forcera à n'avoir qu'une seule instance de TSmtpCli
Alors qu'en OO, tu pourrais conserver plusieurs TSmtpCli et plusieurs receveurs d'EventHandler pour ne mélanger les traitements

Sinon en D7, tu peux fournir une class procedure ça passe normalement pour un TNotifyEvent
Cela évite d'avoir une instance !

Self en théorie devrait être la méta-classe, disons que j'éviterais de l'utiliser dans cette situation (même problématique qu'en procédure, perte du receveur de la méthode)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

implementation   type TSmtpCliEventHander = class private class procedure MonOnSessionConnected(Sender: TObject; ErrCode: Word); end;     class procedure TSmtpCliEventHander.MonOnSessionConnected(Sender: TObject; ErrCode: Word); begin // ............ end;

---

Code:

---

FSmtpCli.OnSessionConnected := TSmtpCliEventHander.MonOnSessionConnected;

---