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)
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; |
FSmtpCli.OnSessionConnected := TSmtpCliEventHander.MonOnSessionConnected;
Partager