Apprendre à envoyer des mails avec Delphi
Un tutoriel de Robin Valtot
Le 2017-03-20 09:09:42, par gvasseur58, Responsable Lazarus & Pascal
Ce tutoriel de Robin Valtot, réalisé avec la version 10.1.2 Berlin (Entreprise et Starter) de Delphi, a pour objectif de montrer plusieurs façons d'envoyer un mail au moyen de cet EDI.
S'appuyant sur la présence d'un client de messagerie, seront tour à tour étudiés un serveur SMTP, le pilotage d'Outlook et la mise en œuvre de l'ensemble MAPI.
http://robin-valtot.developpez.com/t...s-avec-delphi/
L'équipe Delphi de developpez.com profite de cette publication pour féliciter chaleureusement l'auteur de ce tutoriel qui vient d'être promu MVP Delphi : c'est la juste reconnaissance des qualités et du travail de ce jeune collaborateur. Bravo Robin, et merci pour tes contributions à la communauté !
Et vous ?
Que pensez-vous de ce tutoriel ?
Comment utilisez-vous Delphi pour tout ce qui touche au Web ?
Retrouver les meilleurs cours et tutoriels pour apprendre Delphi
Retrouver les meilleurs cours et tutoriels pour apprendre la programmation
S'appuyant sur la présence d'un client de messagerie, seront tour à tour étudiés un serveur SMTP, le pilotage d'Outlook et la mise en œuvre de l'ensemble MAPI.
L'équipe Delphi de developpez.com profite de cette publication pour féliciter chaleureusement l'auteur de ce tutoriel qui vient d'être promu MVP Delphi : c'est la juste reconnaissance des qualités et du travail de ce jeune collaborateur. Bravo Robin, et merci pour tes contributions à la communauté !
Et vous ?
-
Paul TOTHExpert éminent séniorje crois que c'est ce qui me distingue des développeurs académiques, j'ai commencé la programmation tout seul sur un commodore 64 dans les années 80, j'ai découvert la programmation objet tout seul avec la doc de Turbo Pascal 5.5, j'ai découvert les interfaces quand elles ont été ajoutées à Delphi (2 ou 3 je ne sais plus)....bref j'ai une approche de la programmation très empirique et autodidacte...de nos jours Internet permet d'avoir toute la doc que l'on veux sur tous les sujets...mais ce que je vois c'est plus souvent "il faut appliquer les règles" que des explications sur le pourquoi...or à mon sens le pourquoi est fondamental, les règles sont secondaires et j'aime les transgresser car je sais pourquoi je le faisle 25/03/2017 à 11:53
-
retwasMembre expérimentéMerci Gilles
Si vous souhaitez que je développe un sujet précis la prochaine fois, vous pouvez m'en parler : je ferai mon possible pour les prochains articlesle 20/03/2017 à 20:24 -
Paul TOTHExpert éminent séniorles interfaces c'est un juste un outil, des fois il est pratique de s'en servir.
1) pour les DLL
dans Delphi 7 Studio, et notamment le chapitre 19 qui est disponible en ligne, je parle entre autre des plugins. Il n'est pas possible de partager un objet entre une DLL et un EXE sous Delphi, mais avec une Interface ça ne pose aucun problème.
2) l'héritage multiple
dans la POO si tu veux manipuler deux objets différents par le même code, ils doivent avoir un ancêtre commun. Grâce aux interfaces tu peux lever cette limitation très facilement (j'en parle ici d'ailleurs).
techniquement, une interface est un tableau de méthodes, dans Delphi 7 Studio je montre d'ailleurs qu'on peut très bien manipuler les interface à partir d'un simple RECORD
Quand un objet implémente une interface donnée, c'est qu'il est capable de fournir un tableau contenant l'adresse de toutes les méthodes de l'interface dans un ordre établi. Du coup l'objet qui utilise ce tableau peu invoquer la méthode n°x car il sait que c'est la fonction attendue.
tu peux même faire les choses à l'envers, imaginons que tu as deux objets qui ont une fonction Draw(Canvas: TCanvas), les deux fonctions sont totalement différentes , ne sont pas virtuelles, mais tu voudrais pouvoir appeler indifféremment l'une ou l'autre en plaçant ces objets dans un TList, ce n'est pas possible en POO, mais si tu ajoutes l'Interface suivante à ces deux objets;
Code : 1
2
3
4
5
6
7
8
9
10
11
12
13IDraw = interface // ajouter ici un GUID généré par Ctrl+Shift+G procedure Draw(Canvas: TCanvas); end; TObjet1 = class(..., IDraw) procedure Draw(Canvas: TCanvas); end; TObjec2 = class(..., IDraw) procedure Draw(Canvas: TCanvas); end;
et ça c'est plutôt pratique...le seul bémol c'est que toute interface implique l'usage de IInterface qui ajoute AddRef et Release pour gérer la durée de vie de l'objet et si tu ne dérives pas de TInterfacedObject ou TComponent tu dois aussi ajouter ces méthodes.
si tu parles de ce TMouse3D, c'est normal, c'est un objet COMle 22/03/2017 à 9:26 -
SergioMasterRédacteur/ModérateurBonjour,
perso, j'ai été dérouté, envoyer des mails, on avait déjà les FAQs, quelques tutoriels et les exemples d'Indy et je me disais (à tort peut être) à quoi bon
En fait c'est plus l'approche par l'intermédiaire des interfaces pour utiliser les différentes possibilités qui est intéressante, à mon avis il aurait fallu plus expliquer le pourquoi de cette démarche.
Ceci étant, bravo, je sais qu'il est difficile d'écrire des tutoriels, surtout si l'on n'est pas un littéraire. J’espère que beaucoup d'autres membres se sentent aussi des talents d'auteursle 21/03/2017 à 7:58 -
Bernard BMembre avertiBien il semble que les interface permettent de séparer l'utilisation de la mécanique interne. Mais dans la POO de base c'est bien la différence entre public et private.
L'article dont retwas me donne le lien, je l'avais déjà parcouru il y a un certain temps. Je l'ai relu et je suis toujours aussi dubitatif. C'est compliqué et finalement on ne voit pas surgir l'élément incontournable qui fait que l'on s'y colle.
Je n'avais pas tout suivi et rebelote c'est compliqué pour quoi ?
Je dois dire que l'exemple que donne Paul est assez impressionnant. Perso je n'y comprend rien ! et le pire c'est que l'on ne devine pas à quoi cela peut conduire.
La POO suivant son implémentation ce n'est pas toujours simple, mais les interfaces ressemblent à la forêt vierge.
Les cerveaux plus jeunes sont certainement plus malléables mais là le mien à atteint le seuil de son incompétence !le 21/03/2017 à 20:52 -
gbegregMembre expertFélicitations Retwas
As tu pu avancer sur ton autre tutoriel en cours (le jeu du Démineur en FMX) ? Car il est également très bien !
Je comprendrai parfaitement que tu n'ai pas eu le temps : je n'ai pas avancé moi non plus sur mon prochain tuto (remake du jeu The Light Corridor)le 20/03/2017 à 23:48 -
retwasMembre expérimentéJ'ai testé sur le serveur Exchange je n'ai pas eu de problème
Merci gbegreg
Pour le démineur je vais me pencher à nouveau dessus ce mois ci, il me reste seulement le soucis des images sur la version mobile ..
Hâte de voir ton second tutoriel, je connais pas le jeu original, je dois être trop jeune
Merci pour tes remarques et effectivement je suis loin d'être littéraire..
Les interfaces permettent justement d'apporter quelque chose de nouveau par rapport aux autres tutoriels ou FAQ et de passer cette impression de "déjà vu".
Merci Bernard B, je suis curieux de connaitre ton retour
Les interfaces sont là pour apporter quelque chose de nouveau par rapport aux tutoriels existants mais aussi montrer une autre façon de coder.
Une interface ne peut contenir que des méthodes (public) c'est pourquoi il y a des getter et setter.
Si tu as besoin il y a une explication ici ou alors dans l'excellent livre de Nick Hodges "Coding in Delphi".
Le point fort des interfaces est de permettre de découpler son code, limiter la dépendance des classes, avoir un code plus clair, plus propre et plus facile à maintenir, de proposer uniquement la ou les méthodes nécessaires et pas forcément travailler avec/sur l'objet en entier, la portée d'une interface permet aussi de se passer de sa libération.
Cela permettra de voir un peu plus tard les injections de dépendances.
Quoi qu'il en soit, comme le souligne Paul TOTH cela est aussi possible avec des classes "normales"le 21/03/2017 à 11:21 -
joc02Membre habituéComme le dit "Paul Toth", les interfaces peuvent résoudre certains problèmes de base.
Mais si on va un peu plus loin, les interfaces sont un élément de base de la programmation-objet. Effectivement la POO vous donne accès aux portées (private, public, ....). Mais cela serait vraiment trop restrictif de se limiter aux portées et au polymorphisme.
Lorsque vous avez appris le dev, on vous a expliqué quelques règles de bases :
- Si on connait le nombre d'itération et que l'on veut tout parcourir alors on utilise un FOR
- Si on ne connait pas le nombre d'itération ou si l'on souhaite sortir avant d'avoir parcouru tous les items alors on utilise un WHILE
- Ne pas copier-coller du code, mais en faire une procédure
...
Pour le développement objet c'est pareil il y a des règles. Et une des règles de bases est de concevoir ses objets par composition. Afin que chacune des responsabilités de classe soit bien séparée. Les interfaces deviennent donc quasi obligatoires.
Certains développeurs utilisent cette méthodologie :
- Ecriture des interfaces
- Ecriture des classes
- Implémentation
- Test fonctionnel (soit test unitaire / soit sous console dos)
- Implémentation de l'interface graphique.le 24/03/2017 à 14:47 -
der§enMembre éprouvéCurieux de voir si cela fonctionne avec un Exchange serveur…le 20/03/2017 à 22:38
-
Bernard BMembre avertiBeau tuto bien fait !
Par contre en tant que vieux développeur autodidacte qui a commencé en Turbo pascal sur Amstrad (les jeunes zont jamais vu !!) je ne comprend pas tout !
Les interfaces, je rejoins SergioMaster, elles apportent quoi de plus ? Je n'y vois qu'une couche de complexité supplémentaire. Peut-on m'éclairer ?
Autre interrogation : dans l'objet TMessageSenderSMTP pourquoi faire des get et des set dans la gestion des property alors qu'il me semble qu'une simple référence à la variable interne fait l'affaire.
Je vais tester de ce pas car je suis en plein dans l'envoi de mails !
Actuellement j'utilise plutôt l'objet SmtpClient de ICS car je trouve la bibli Indy horriblement compliquée et assez mal documentée.le 21/03/2017 à 9:29