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