Discussion :

[Ju2Pom]

Bonjour tout le monde

J'ai crée une petite fenêtre qui se lance lorsque l'utilisateur clique sur un bouton afin d'envoyer un email, avec un fichier en pièce jointe.

Cette fenêtre a pour but de faire patienter l'utilisateur : affichage de la progression du traitement de l'envoi de l'email. J'utilise pour cela le composant TCGauge (onglets Samples), car il me permet d'afficher la progression en % .
Je pense que la Progress Bar aurait également fait l'affaire.

Pour envoyer l'email j'utilise le composant TIdSMTP (onglets Indy Clients).

Mon probleme est le suivant : l'email arrive bien a destination ainsi que sa pièce jointe, j'arrive à faire progresser ma barre en temps réel, mais pas de manière proportionnelle !

Je m'explique : le but du jeu est d'afficher je pense dans ma jauge de progression, l'état à un instant T du nombre d'octets envoyés.

Sur le composant TIdSMTP , il existe 3 événements :
- OnWorkBegin : appelé dès que j'envoie l'email
- OnWork : appelé à plusieurs reprises lors du traitement d'envoi d'email
- OnWorkEnd : lorsque l'envoi est terminé

J'ai donc eu l'idée de mesurer avant d'envoyer un email, la taille en octets du fichier joint.

Je recupère cette taille, et j'affecte donc à ma jauge sur le WorkBegin, la valeur maximum, en positionnant la valeur de départ à 0

Code :

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

1
2
3
4
5
6
7
 
void __fastcall TfrmEnvoiEmail::SMTPConnecWorkBegin(TObject *Sender,
      TWorkMode AWorkMode, const int AWorkCountMax)
{
        cggeProgress->Progress = 0;
        cggeProgress->MaxValue = TailleFicJoint;
}

A noter que la valeur "AWorkCountMax" passée en paramètre me renvoie 0, donc je ne vois pas trop a quoi celle-ci peut me servir ... Pourtant dans l'aide cette variable est censée représenter le nombre d'octets qui vont être envoyés.

Sur le Work, j'actualise ma barre de la sorte (et c'est ici que je nécessite votre aide)

Code :

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

1
2
3
4
5
6
 
void __fastcall TfrmEnvoiEmail::SMTPConnecWork(TObject *Sender,
      TWorkMode AWorkMode, const int AWorkCount)
{
        cggeProgress->Progress += cggeProgress->MaxValue*0.01;
}

Cette incrémentation est totalement arbitraire, je pense qu'il faut que j'utilise la valeur AWorkCount qui devrait me renvoyer le nombre d'octets déja envoyés à cet instant T.

Le problème c'est que vers la fin de l'envoi, cette valeur est SUPERIEURE à la taille en octet de mon fichier joint. Je pense que ceci est normal, puisqu"il y a également les informations comme le corps du message, l'adresse expediteur, l'adresse destinataire etc ...

Alors comment faire pour calculer équitablement et proportionnellement la progression de l'envoi ? Comment connaitre à l'avance le nombre d'octets TOTAL qui vont être envoyés ? (j'ai déja la taille du fichier, comment recupérer la taille des informations "textes" de l'email ...) ??

Sur le WorkEnd, bien sûr je fais :

Code :

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

1
2
3
4
5
6
7
 
void __fastcall TfrmEnvoiEmail::SMTPConnecWorkEnd(TObject *Sender,
      TWorkMode AWorkMode)
{
        cggeProgress->Progress =  cggeProgress->MaxValue;
 
}

Si quelqu'un a déja été confronté à cette problématique, je suis preneur

Car en effet, même si ma jauge progresse, son avancement de représente pas le réel état du traitement ... la jauge va par exemple sur un fichier joint de 2 Mo mettre 20 secondes pour arriver à 60%, pui hop sauter en l'espace de 2 secondes à 100%. Certes pour l'utilisateur, cela ne change pas grand chose, mais étant perfectionniste, j'aimerais améliorer tout cela

Merci d'avance

[Altau]

Le problème c'est que vers la fin de l'envoi, cette valeur est SUPERIEURE à la taille en octet de mon fichier joint. Je pense que ceci est normal, puisqu"il y a également les informations comme le corps du message, l'adresse expediteur, l'adresse destinataire etc ...

Ben non, la taille d'un message ne dépend pas tant de ces informations d'en-tête que du codage Mime du message. On s'en aperçoit d'ailleurs couramment quand on reçoit un message qui est toujours beaucoup plus gros que ses pièces jointes. Je n'utilise pas les composants Indy pour ce genre de traitement (j'utilise plutôt ICS) mais il faudrait que tu trouves le moyen de connaître la taille du message qui sera envoyé une fois le codage Mime effectué ; la taille d'origine de tes pièces jointes ne convient pas.

[Ju2Pom]

le moyen de connaître la taille du message qui sera envoyé une fois le codage Mime effectué ; la taille d'origine de tes pièces jointes ne convient pas.

Bien compris, merci pour ta réponse, mais je ne sais toujours pas comment faire pour recuperer cette taille du message ?

Quelqu'un a une 'tite idée ?

[Patrick Seuret]

Sauf erreur, le codage MIME des pièces jointes code les octets sur 7 bits. Je m'explique: le protocole n'assurant pas le passage correct des caractères ASCII de code supérieur à 128, il faut bien qu'on arrive à placer le bit de poids le plus haut dans le message. Cela se fait bêtement en décalant ce bit dans le caractère suivant (et on met 0 comme bit hi). Le caractère suivant est lui aussi décalé d'un bit et ses deux bits de poids les plus hauts sont dans le suivant, etc, etc.

Si je veux transmettre les bits suivants (chaque lettre est un bit, chaque parenthèse un octet:

(ABCDEFGH)(IJKLMNOP)(QRSTUVWX)

Alors le code mime est:

(0ABCDEFG)(0HIJKLMN)(0OPQRSTU)(0VWX)

(je me trompe peut-être dans l'ordre des décalages...)

Donc, la taille finale de ma pièce jointe est de 1 bit supplémentaire pour chaque octet, soit approximativement:
(taille finale)=(taille initiale)*9/8

Avec des tailles en octet. dans notre exemple: 3 octets au départ donnent 3*9/8=3.38 (en réalité 3.5 car il y avait encore un bit pour le dernier octet).

Il y a en plus des informations de structures qui s'ajoutent à cet encodage...

Si vous voulez plus d'information, il faut chercher sous UUEncode sur la wiki ou ailleurs

[Ju2Pom]

Bonjour à tous et encore merci pour vos réponses !

Apres plusieurs recherches sur les forums, il n'est donc à priori pas possible de définir à l'avance l'EXACTE taille totale de l'email qui sera envoyé.

En revanche il est possible de maximiser une approximation, un peu grossière certes, qui me convient tout à fait dans mon cas.

Dans le OnWorkBegin, je calcule donc cette approximation, en sommant la taille de toutes mes pièces jointes.

Ensuite j'ajoute à TailleMax le reste de mon message :

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
 
 
//rajout de toutes les informations d'en tête, corps de message etc ...
        TailleMax = TailleMax + obj_TIDMessage->BccList->EMailAddresses.Length();
        TailleMax = TailleMax + obj_TIDMessage->CCList->EMailAddresses.Length();
        TailleMax = TailleMax + obj_TIDMessage->Body->Text.Length();
        TailleMax = TailleMax + obj_TIDMessage->From->Text.Length();
        TailleMax = TailleMax + obj_TIDMessage->ExtraHeaders->Text.Length();
        TailleMax = TailleMax + obj_TIDMessage->Headers->Text.Length();
        TailleMax = TailleMax + obj_TIDMessage->Recipients->EMailAddresses.Length();
        TailleMax = TailleMax + obj_TIDMessage->References.Length();
        TailleMax = TailleMax + obj_TIDMessage->Subject.Length();
 
 
        //il reste également des informations (commandes de controle, infos supplementaires d'encodages et de formatage du stream
        //ponderation assez "arbitraire" de 1.40 censé représentée ces infos
        TailleMax = RoundTo(TailleMax * 1.4,0);

J'affecte par la suite suite au MaxValue de ma barre de progression, ma variable TailleMax.

Ne voulant pas recréer de nouveau sujet, je me pose maintenant une nouvelle question !

J'aimerais offrir la possibilité à l'utilisateur d'annuler via le clic d'un bouton, l'envoi d'un email (pièce jointe ou pas) qui est en cours...

Et donc, bien sûr que l'email n'arrive pas à destination ...

Est ce possible ? Sur mon objet TidSMTP, si j'applique la méthode Disconnect(), j'ai une exception "la connexion s'est terminée proprement" !

Dois je vider un quelconque buffer au préalable ?

D'avance merci