J'=E9tais habitu=E9 avec d'autres langages =E0 trouver =E0 t=E9l=E9charge=
r des=20
routines assez simples =E0 utiliser pour lire des mails. D'ailleurs c'est=
=20
simple, =E0 ce que je me rappelle sur salemioche.com (mais d=E9m=E9nag=E9=
=20
depuis) on trouvait une page qui pr=E9sentait le protocole POP, et par=20
ailleurs l'impl=E9mentation en VB6.
Sous C#, j'ai l'impression qu'il y a eu moins de monde sur la question.
J'ai quand m=EAme trouv=E9 quelque chose d'int=E9ressant l=E0 :
http://www.csharpfr.com/codes/CLIENT-POP3_11467.aspx
En client lourd on trouve l=E0 un travail sur les pi=E8ces jointes, qui p=
eut=20
n=E9cessiter quelques petites mises au point mais reste int=E9ressant com=
me=20
point de d=E9part sur ce sujet, mais est plus lourd =E0 adapter en client=
=20
l=E9ger :
http://www.csharpfr.com/codes/INTERFACE-POPMAIL-PIECES-JOINTES_11559.aspx=
Pour rappel le client l=E9ger est l'application qui s'attache =E0 affiche=
r=20
le plus rapidement possible la liste des mails re=E7us, et pour favoriser=
=20
la rapidit=E9 r=E9alise peu ou pas de traitement sur le corps de chaque=20
mail. J'en ai par exemple r=E9alis=E9 un avec un reportViewer, ce qui per=
met=20
d'imprimer la liste des mails, qui peut =EAtre int=E9ressante avant de=20
purger le serveur.
Il me semble bien avoir travaill=E9 aussi avec quelque chose=20
d'interm=E9diaire entre le client l=E9ger et le traitement des pi=E8ces=20
jointes, mais ce que je retrouve =E0 cet instant est en VB6.
A pr=E9sent, comme j'ai plusieurs applications =E0 =E9crire faisant inter=
venir=20
des mails, je m'attaque =E0 une DLL =E0 appeler depuis une application=20
WinForm ou un site web. =E7a commence =E0 fonctionner, je suppose que ce =
qui=20
va arriver est que je vais mettre en =9Cuvre ce qui manque sur mon site, =
et revenir l=E0-dessus ensuite.
Ce type de d=E9veloppement =E9tant destin=E9 =E0 =EAtre utilis=E9 dans de=
nombreuses=20
applications, il est pr=E9f=E9rable qu'il corresponde aux souhaits d'un=20
grand nombre. Aussi, j'=E9num=E8re les grandes lignes, de fa=E7on qu'on p=
uisse=20
m'indiquer quelque chose qui para=EEt manquer.
Par ailleurs, un travail (non publi=E9 me semble-t-il) a =E9t=E9 r=E9alis=
=E9 sur=20
le premier projet mentionn=E9 ci-dessus pour d=E9coder les sujets (et=20
accessoirement les noms des correspondants puisqu'ils peuvent aussi =EAtr=
e=20
=E9crits avec des caract=E8res accentu=E9s), toutefois ce travail ne g=E8=
re pas=20
encore les UTF8. En cherchant quelque chose l=E0-dessus je vais bien=20
trouver, est-ce que je peux cette fois esp=E9rer arriver =E0 quelque chos=
e=20
d'exhaustif sur le d=E9codage des sujets ? J'ai commenc=E9 par chercher=20
quelque chose de tout pr=EAt, mais en vain. A ce stade le d=E9codage=20
fonctionne en jeu de caract=E8res constant.
A ce stade, voici ce qui fonctionne sur ce dont je parle :
- connexion avec les informations re=E7ues en param=E8tres du constructeu=
r,=20
site, nom d'utilisateur, mot de passe ; le tout sur le port 110 en=20
protocole POP
- information de l'utilisateur =E0 l'aide de deux d=E9l=E9gu=E9s, fournis=
sant=20
deux niveaux d'information (ce que sur le projet ci-dessus on trouve=20
respectivement dans la barre d'=E9tat et le richtextbox).
- sur chaque message il est possible d'obtenir la date, le sujet,=20
l'=E9metteur (from), le destinataire (to), du dernier message lu, et=20
l'int=E9gralit=E9 du message, ceci n=E9cessitant bien entendu une connexi=
on=20
plus longue (par d=E9faut on ne lit que les 30 premi=E8res lignes du mess=
age=20
pour avoir les ent=EAtes, et lorsque l'application appelante demande=20
l'int=E9gralit=E9 du message on relance une lecture sur le serveur)
- =E0 r=E9aliser dans quelques semaines : internationalisation de ce=20
traitement, pour le moment les messages sont conserv=E9s dans la langue=20
d'origine
Au point o=F9 j'en suis le stockage des informations de connexion puis de=
s=20
mails re=E7us est du ressort de l'application appelante. Il ne me para=EE=
t=20
d'ailleurs pas exclu d'en rester l=E0 sur ce point, d'autant que le=20
stockage de param=E8tres d'application crypt=E9s se fait de mani=E8re=20
diff=E9rente en Winform et en Webform.
Bonjour, S'il n'y a pas grand monde sur le sujet, c'est peut-être parce qu'il y a IMAP ?
"Gloops" a écrit dans le message de news: Bonjour tout le monde,
J'étais habitué avec d'autres langages à trouver à télécharger des routines assez simples à utiliser pour lire des mails. D'ailleurs c'est simple, à ce que je me rappelle sur salemioche.com (mais déménagé depuis) on trouvait une page qui présentait le protocole POP, et par ailleurs l'implémentation en VB6.
Sous C#, j'ai l'impression qu'il y a eu moins de monde sur la question.
J'ai quand même trouvé quelque chose d'intéressant là : http://www.csharpfr.com/codes/CLIENT-POP3_11467.aspx
En client lourd on trouve là un travail sur les pièces jointes, qui peut nécessiter quelques petites mises au point mais reste intéressant comme point de départ sur ce sujet, mais est plus lourd à adapter en client léger : http://www.csharpfr.com/codes/INTERFACE-POPMAIL-PIECES-JOINTES_11559.aspx
Pour rappel le client léger est l'application qui s'attache à afficher le plus rapidement possible la liste des mails reçus, et pour favoriser la rapidité réalise peu ou pas de traitement sur le corps de chaque mail. J'en ai par exemple réalisé un avec un reportViewer, ce qui permet d'imprimer la liste des mails, qui peut être intéressante avant de purger le serveur.
Il me semble bien avoir travaillé aussi avec quelque chose d'intermédiaire entre le client léger et le traitement des pièces jointes, mais ce que je retrouve à cet instant est en VB6.
A présent, comme j'ai plusieurs applications à écrire faisant intervenir des mails, je m'attaque à une DLL à appeler depuis une application WinForm ou un site web. ça commence à fonctionner, je suppose que ce qui va arriver est que je vais mettre en œuvre ce qui manque sur mon site, et revenir là-dessus ensuite.
Ce type de développement étant destiné à être utilisé dans de nombreuses applications, il est préférable qu'il corresponde aux souhaits d'un grand nombre. Aussi, j'énumère les grandes lignes, de façon qu'on puisse m'indiquer quelque chose qui paraît manquer.
Par ailleurs, un travail (non publié me semble-t-il) a été réalisé sur le premier projet mentionné ci-dessus pour décoder les sujets (et accessoirement les noms des correspondants puisqu'ils peuvent aussi être écrits avec des caractères accentués), toutefois ce travail ne gère pas encore les UTF8. En cherchant quelque chose là-dessus je vais bien trouver, est-ce que je peux cette fois espérer arriver à quelque chose d'exhaustif sur le décodage des sujets ? J'ai commencé par chercher quelque chose de tout prêt, mais en vain. A ce stade le décodage fonctionne en jeu de caractères constant.
A ce stade, voici ce qui fonctionne sur ce dont je parle : - connexion avec les informations reçues en paramètres du constructeur, site, nom d'utilisateur, mot de passe ; le tout sur le port 110 en protocole POP - information de l'utilisateur à l'aide de deux délégués, fournissant deux niveaux d'information (ce que sur le projet ci-dessus on trouve respectivement dans la barre d'état et le richtextbox). - sur chaque message il est possible d'obtenir la date, le sujet, l'émetteur (from), le destinataire (to), du dernier message lu, et l'intégralité du message, ceci nécessitant bien entendu une connexion plus longue (par défaut on ne lit que les 30 premières lignes du message pour avoir les entêtes, et lorsque l'application appelante demande l'intégralité du message on relance une lecture sur le serveur) - à réaliser dans quelques semaines : internationalisation de ce traitement, pour le moment les messages sont conservés dans la langue d'origine
Au point où j'en suis le stockage des informations de connexion puis des mails reçus est du ressort de l'application appelante. Il ne me paraît d'ailleurs pas exclu d'en rester là sur ce point, d'autant que le stockage de paramètres d'application cryptés se fait de manière différente en Winform et en Webform.
Bonjour,
S'il n'y a pas grand monde sur le sujet, c'est peut-être parce qu'il y a
IMAP ?
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de
news:e9m9r1ZKKHA.4432@TK2MSFTNGP02.phx.gbl...
Bonjour tout le monde,
J'étais habitué avec d'autres langages à trouver à télécharger des
routines assez simples à utiliser pour lire des mails. D'ailleurs c'est
simple, à ce que je me rappelle sur salemioche.com (mais déménagé
depuis) on trouvait une page qui présentait le protocole POP, et par
ailleurs l'implémentation en VB6.
Sous C#, j'ai l'impression qu'il y a eu moins de monde sur la question.
J'ai quand même trouvé quelque chose d'intéressant là :
http://www.csharpfr.com/codes/CLIENT-POP3_11467.aspx
En client lourd on trouve là un travail sur les pièces jointes, qui peut
nécessiter quelques petites mises au point mais reste intéressant comme
point de départ sur ce sujet, mais est plus lourd à adapter en client
léger :
http://www.csharpfr.com/codes/INTERFACE-POPMAIL-PIECES-JOINTES_11559.aspx
Pour rappel le client léger est l'application qui s'attache à afficher
le plus rapidement possible la liste des mails reçus, et pour favoriser
la rapidité réalise peu ou pas de traitement sur le corps de chaque
mail. J'en ai par exemple réalisé un avec un reportViewer, ce qui permet
d'imprimer la liste des mails, qui peut être intéressante avant de
purger le serveur.
Il me semble bien avoir travaillé aussi avec quelque chose
d'intermédiaire entre le client léger et le traitement des pièces
jointes, mais ce que je retrouve à cet instant est en VB6.
A présent, comme j'ai plusieurs applications à écrire faisant intervenir
des mails, je m'attaque à une DLL à appeler depuis une application
WinForm ou un site web. ça commence à fonctionner, je suppose que ce qui
va arriver est que je vais mettre en œuvre ce qui manque sur mon site,
et revenir là-dessus ensuite.
Ce type de développement étant destiné à être utilisé dans de nombreuses
applications, il est préférable qu'il corresponde aux souhaits d'un
grand nombre. Aussi, j'énumère les grandes lignes, de façon qu'on puisse
m'indiquer quelque chose qui paraît manquer.
Par ailleurs, un travail (non publié me semble-t-il) a été réalisé sur
le premier projet mentionné ci-dessus pour décoder les sujets (et
accessoirement les noms des correspondants puisqu'ils peuvent aussi être
écrits avec des caractères accentués), toutefois ce travail ne gère pas
encore les UTF8. En cherchant quelque chose là-dessus je vais bien
trouver, est-ce que je peux cette fois espérer arriver à quelque chose
d'exhaustif sur le décodage des sujets ? J'ai commencé par chercher
quelque chose de tout prêt, mais en vain. A ce stade le décodage
fonctionne en jeu de caractères constant.
A ce stade, voici ce qui fonctionne sur ce dont je parle :
- connexion avec les informations reçues en paramètres du constructeur,
site, nom d'utilisateur, mot de passe ; le tout sur le port 110 en
protocole POP
- information de l'utilisateur à l'aide de deux délégués, fournissant
deux niveaux d'information (ce que sur le projet ci-dessus on trouve
respectivement dans la barre d'état et le richtextbox).
- sur chaque message il est possible d'obtenir la date, le sujet,
l'émetteur (from), le destinataire (to), du dernier message lu, et
l'intégralité du message, ceci nécessitant bien entendu une connexion
plus longue (par défaut on ne lit que les 30 premières lignes du message
pour avoir les entêtes, et lorsque l'application appelante demande
l'intégralité du message on relance une lecture sur le serveur)
- à réaliser dans quelques semaines : internationalisation de ce
traitement, pour le moment les messages sont conservés dans la langue
d'origine
Au point où j'en suis le stockage des informations de connexion puis des
mails reçus est du ressort de l'application appelante. Il ne me paraît
d'ailleurs pas exclu d'en rester là sur ce point, d'autant que le
stockage de paramètres d'application cryptés se fait de manière
différente en Winform et en Webform.
Bonjour, S'il n'y a pas grand monde sur le sujet, c'est peut-être parce qu'il y a IMAP ?
"Gloops" a écrit dans le message de news: Bonjour tout le monde,
J'étais habitué avec d'autres langages à trouver à télécharger des routines assez simples à utiliser pour lire des mails. D'ailleurs c'est simple, à ce que je me rappelle sur salemioche.com (mais déménagé depuis) on trouvait une page qui présentait le protocole POP, et par ailleurs l'implémentation en VB6.
Sous C#, j'ai l'impression qu'il y a eu moins de monde sur la question.
J'ai quand même trouvé quelque chose d'intéressant là : http://www.csharpfr.com/codes/CLIENT-POP3_11467.aspx
En client lourd on trouve là un travail sur les pièces jointes, qui peut nécessiter quelques petites mises au point mais reste intéressant comme point de départ sur ce sujet, mais est plus lourd à adapter en client léger : http://www.csharpfr.com/codes/INTERFACE-POPMAIL-PIECES-JOINTES_11559.aspx
Pour rappel le client léger est l'application qui s'attache à afficher le plus rapidement possible la liste des mails reçus, et pour favoriser la rapidité réalise peu ou pas de traitement sur le corps de chaque mail. J'en ai par exemple réalisé un avec un reportViewer, ce qui permet d'imprimer la liste des mails, qui peut être intéressante avant de purger le serveur.
Il me semble bien avoir travaillé aussi avec quelque chose d'intermédiaire entre le client léger et le traitement des pièces jointes, mais ce que je retrouve à cet instant est en VB6.
A présent, comme j'ai plusieurs applications à écrire faisant intervenir des mails, je m'attaque à une DLL à appeler depuis une application WinForm ou un site web. ça commence à fonctionner, je suppose que ce qui va arriver est que je vais mettre en œuvre ce qui manque sur mon site, et revenir là-dessus ensuite.
Ce type de développement étant destiné à être utilisé dans de nombreuses applications, il est préférable qu'il corresponde aux souhaits d'un grand nombre. Aussi, j'énumère les grandes lignes, de façon qu'on puisse m'indiquer quelque chose qui paraît manquer.
Par ailleurs, un travail (non publié me semble-t-il) a été réalisé sur le premier projet mentionné ci-dessus pour décoder les sujets (et accessoirement les noms des correspondants puisqu'ils peuvent aussi être écrits avec des caractères accentués), toutefois ce travail ne gère pas encore les UTF8. En cherchant quelque chose là-dessus je vais bien trouver, est-ce que je peux cette fois espérer arriver à quelque chose d'exhaustif sur le décodage des sujets ? J'ai commencé par chercher quelque chose de tout prêt, mais en vain. A ce stade le décodage fonctionne en jeu de caractères constant.
A ce stade, voici ce qui fonctionne sur ce dont je parle : - connexion avec les informations reçues en paramètres du constructeur, site, nom d'utilisateur, mot de passe ; le tout sur le port 110 en protocole POP - information de l'utilisateur à l'aide de deux délégués, fournissant deux niveaux d'information (ce que sur le projet ci-dessus on trouve respectivement dans la barre d'état et le richtextbox). - sur chaque message il est possible d'obtenir la date, le sujet, l'émetteur (from), le destinataire (to), du dernier message lu, et l'intégralité du message, ceci nécessitant bien entendu une connexion plus longue (par défaut on ne lit que les 30 premières lignes du message pour avoir les entêtes, et lorsque l'application appelante demande l'intégralité du message on relance une lecture sur le serveur) - à réaliser dans quelques semaines : internationalisation de ce traitement, pour le moment les messages sont conservés dans la langue d'origine
Au point où j'en suis le stockage des informations de connexion puis des mails reçus est du ressort de l'application appelante. Il ne me paraît d'ailleurs pas exclu d'en rester là sur ce point, d'autant que le stockage de paramètres d'application cryptés se fait de manière différente en Winform et en Webform.
J-L
> message, ceci nécessitant bien entendu une connexion plus longue (par défaut on ne lit que les 30 premières lignes du message pour avoir les entêtes, et lorsque l'application appelante demande l'intégralité du message on relance
les 30 premières lignes de quoi ? du corps de l'email ? du cource complet de l'email ?
As-tu pensé à récupérer les CC et CCI ?
> message, ceci nécessitant bien entendu une connexion plus longue (par défaut
on ne lit que les 30 premières lignes du message pour avoir les entêtes, et
lorsque l'application appelante demande l'intégralité du message on relance
les 30 premières lignes de quoi ?
du corps de l'email ?
du cource complet de l'email ?
> message, ceci nécessitant bien entendu une connexion plus longue (par défaut on ne lit que les 30 premières lignes du message pour avoir les entêtes, et lorsque l'application appelante demande l'intégralité du message on relance
les 30 premières lignes de quoi ? du corps de l'email ? du cource complet de l'email ?
As-tu pensé à récupérer les CC et CCI ?
Gloops
J-L a écrit, le 31/08/2009 09:43 :
message, ceci nécessitant bien entendu une connexion plus longue (pa r défaut on ne lit que les 30 premières lignes du message pour avoir les entêtes, et lorsque l'application appelante demande l'intégralité du message on relance
les 30 premières lignes de quoi ? du corps de l'email ? du cource complet de l'email ?
A ton avis, pour connaître l'expéditeur, le destinataire, la date ?
As-tu pensé à récupérer les CC et CCI ?
Effectivement j'y ai pensé depuis, ça ne serait pas une mauvaise idé e. Je vois d'ici venir qu'il faut penser à un moyen de séparer les différents destinataires mentionnés dans le même champ. Soit je ret ourne tout dans la même chaîne et je laisse l'application appelante se débrouiller, soit je retourne un tableau de chaînes. ça peut être valable pour le champ To aussi, d'ailleurs.
J'ai pensé aussi à un champ mot de passe, propre au message, qui peut être utile pour valider une confirmation d'enregistrement à une liste d'informations, par exemple. Je tâcherai de mettre des noms explicites pour qu'on ne le confonde pas avec le mot de passe du compte de mails.
Ce n'est pas un champ officiel défini par les conventions, mais en le mettant en tête du corps de texte, ça devrait passer.
J-L a écrit, le 31/08/2009 09:43 :
message, ceci nécessitant bien entendu une connexion plus longue (pa r
défaut on ne lit que les 30 premières lignes du message pour avoir les
entêtes, et lorsque l'application appelante demande l'intégralité du
message on relance
les 30 premières lignes de quoi ?
du corps de l'email ?
du cource complet de l'email ?
A ton avis, pour connaître l'expéditeur, le destinataire, la date ?
As-tu pensé à récupérer les CC et CCI ?
Effectivement j'y ai pensé depuis, ça ne serait pas une mauvaise idé e.
Je vois d'ici venir qu'il faut penser à un moyen de séparer les
différents destinataires mentionnés dans le même champ. Soit je ret ourne
tout dans la même chaîne et je laisse l'application appelante se
débrouiller, soit je retourne un tableau de chaînes. ça peut être
valable pour le champ To aussi, d'ailleurs.
J'ai pensé aussi à un champ mot de passe, propre au message, qui peut
être utile pour valider une confirmation d'enregistrement à une liste
d'informations, par exemple. Je tâcherai de mettre des noms explicites
pour qu'on ne le confonde pas avec le mot de passe du compte de mails.
Ce n'est pas un champ officiel défini par les conventions, mais en le
mettant en tête du corps de texte, ça devrait passer.
message, ceci nécessitant bien entendu une connexion plus longue (pa r défaut on ne lit que les 30 premières lignes du message pour avoir les entêtes, et lorsque l'application appelante demande l'intégralité du message on relance
les 30 premières lignes de quoi ? du corps de l'email ? du cource complet de l'email ?
A ton avis, pour connaître l'expéditeur, le destinataire, la date ?
As-tu pensé à récupérer les CC et CCI ?
Effectivement j'y ai pensé depuis, ça ne serait pas une mauvaise idé e. Je vois d'ici venir qu'il faut penser à un moyen de séparer les différents destinataires mentionnés dans le même champ. Soit je ret ourne tout dans la même chaîne et je laisse l'application appelante se débrouiller, soit je retourne un tableau de chaînes. ça peut être valable pour le champ To aussi, d'ailleurs.
J'ai pensé aussi à un champ mot de passe, propre au message, qui peut être utile pour valider une confirmation d'enregistrement à une liste d'informations, par exemple. Je tâcherai de mettre des noms explicites pour qu'on ne le confonde pas avec le mot de passe du compte de mails.
Ce n'est pas un champ officiel défini par les conventions, mais en le mettant en tête du corps de texte, ça devrait passer.
Gloops
Jean-Michel Berthier a écrit, le 31/08/2009 09:40 :
Bonjour, S'il n'y a pas grand monde sur le sujet, c'est peut-être parce qu'il y a IMAP ?
Bonjour,
Peut-être, toutefois dans ma recherche je n'ai pas précisé de proto cole.
As-tu des exemples en tête ?
Jean-Michel Berthier a écrit, le 31/08/2009 09:40 :
Bonjour,
S'il n'y a pas grand monde sur le sujet, c'est peut-être parce qu'il y a
IMAP ?
Bonjour,
Peut-être, toutefois dans ma recherche je n'ai pas précisé de proto cole.
Jean-Michel Berthier a écrit, le 31/08/2009 09:40 :
Bonjour, S'il n'y a pas grand monde sur le sujet, c'est peut-être parce qu'il y a IMAP ?
Bonjour,
Peut-être, toutefois dans ma recherche je n'ai pas précisé de proto cole.
As-tu des exemples en tête ?
Gloops
Gloops a écrit, le 31/08/2009 14:14 :
les 30 premières lignes de quoi ? du corps de l'email ? du cource complet de l'email ?
A ton avis, pour connaître l'expéditeur, le destinataire, la date ?
En réalité, tu pointes là un problème important, même si je ne le prendrai vraiment en compte que plus tard. Si le module doit être conç u pour pouvoir être appelé le plus facilement possible par un dévelop peur, en revanche il semble que ça risque d'être hasardeux de s'en servir sans avoir une petite notion de ce que c'est qu'un message mail, comment il est structuré, émis, transmis, éventuellement filtré (et les d eux sens que peuvent recouvrir ce mot), et reçu.
J'imagine que tout cela fait déjà l'objet de documentations en ligne, une fois que tout fonctionnera et sera en ligne il me restera encore à établir quelques liens vers des pages intéressantes. Si tu veux t'y coller, d'ailleurs, ne te gêne pas ...
A défaut, pour le moment je m'adresse donc à des initiés, à savoi r des développeurs suffisamment intéressés par la réception de mails po ur s'être déjà un peu documentés. C'est vrai que toute information f ournie est susceptible d'élargir la cible, je vais passer quelques minutes là-dessus, après pendant que je développe le module (et que je m'en sers, j'ai déjà une liste de projets sous le coude), si d'autres intervenants ont des pistes intéressantes ça permet de faire avancer le schmilblick.
J'ai retrouvé les pages que j'avais lues sur salemioche.net, ce n'est pas dur on y a mis un lien dessus :
http://www.iprelax.fr/pop/ Intéressant pour les développeurs, on entre dans le vif du sujet. Il y a aussi un répertoire imap, d'ailleurs, sur le même serveur.
Et j'ai été très mauvaise langue, car l'exemple fourni là-dessus est maintenant en C# (ou du moins ça ressemble, j'ai toutefois été surp ris, en tête de module, de trouver non pas des using, mais des #include <*.h >).
Les moteurs de recherche c'est bien, mais quand on a connu une bonne adresse, il ne faut pas oublier de revenir y voir :)
Toutefois à présent que j'ai trouvé un traitement qui fonctionne, j e vais m'y tenir sauf objection de l'auteur. L'aspect extraction en DLL à appeler aussi bien en WinForm qu'en web ne semble être pris en compte sur aucune des sources que j'ai consultées (je parle de celles qui publient leurs sources).
Pour un abord beaucoup plus basique (pour les utilisateurs) on a ceci :
http://www.arobase.org/ecole/pop.htm Là, on explique clairement à quoi servent les différents protocoles . On ne se perd pas dans les détails de mise en ½uvre.
http://www.eila.univ-paris-diderot.fr/sysadmin/mail/pop-vs-imap Apparemment la même cible que ci-dessus, avec des illustrations, et divers liens vers plus de détails, que je ne suis pas allé voir.
J'y lis ceci, que je serais tenté de moduler : "Un avantage d'IMAP sur POP est que les messages étant sur le serveur, vos boîtes sont sauvegardés très régulièrement."
Prudence : en effet, à force de recevoir des mails sur un serveur, un jour, comme il n'y a plus de place, il faut les enlever. Il n'est pas forcément clair pour un nouvel utilisateur de ce protocole qu'une fois un message effacé du serveur, il va s'effacer automatiquement de la machine qui le lit. Il convient donc, si on souhaite conserver l'historique de ses mails sur le long terme, d'en réaliser des copies, en local soit avec des filtres comme on les entend dans Eudora ou Thunderbird, soit en réalisant une nouvelle réception avec le protoco le POP. Si on a réalisé ceci avec des filtres d'une application cliente de messagerie, il faut prendre le temps de vérifier que tous les messages souhaités ont bien été sauvegardés en local (d'où l'intérêt de pouvoir en imprimer la liste).
Tout support informatique étant susceptible d'être effacé par exemp le par fausse man½uvre, il convient de conserver cet historique en plusieurs exemplaires. Il revient à chacun d'élaborer sa stratégie de sauvegarde. A l'attention des secrétaires qui ont un jour envoyé des photocopies de disquettes, ou agrafé l'original à un courrier, ce ser ait peut-être un jour une bonne idée de rédiger une stratégie de conservation de mails. Le sujet risque d'être beaucoup moins trivial qu'il n'y paraît de prime abord.
Gloops a écrit, le 31/08/2009 14:14 :
les 30 premières lignes de quoi ?
du corps de l'email ?
du cource complet de l'email ?
A ton avis, pour connaître l'expéditeur, le destinataire, la date ?
En réalité, tu pointes là un problème important, même si je ne le
prendrai vraiment en compte que plus tard. Si le module doit être conç u
pour pouvoir être appelé le plus facilement possible par un dévelop peur,
en revanche il semble que ça risque d'être hasardeux de s'en servir
sans avoir une petite notion de ce que c'est qu'un message mail, comment
il est structuré, émis, transmis, éventuellement filtré (et les d eux
sens que peuvent recouvrir ce mot), et reçu.
J'imagine que tout cela fait déjà l'objet de documentations en ligne,
une fois que tout fonctionnera et sera en ligne il me restera encore à
établir quelques liens vers des pages intéressantes. Si tu veux t'y
coller, d'ailleurs, ne te gêne pas ...
A défaut, pour le moment je m'adresse donc à des initiés, à savoi r des
développeurs suffisamment intéressés par la réception de mails po ur
s'être déjà un peu documentés. C'est vrai que toute information f ournie
est susceptible d'élargir la cible, je vais passer quelques minutes
là-dessus, après pendant que je développe le module (et que je m'en
sers, j'ai déjà une liste de projets sous le coude), si d'autres
intervenants ont des pistes intéressantes ça permet de faire avancer le
schmilblick.
J'ai retrouvé les pages que j'avais lues sur salemioche.net, ce n'est
pas dur on y a mis un lien dessus :
http://www.iprelax.fr/pop/
Intéressant pour les développeurs, on entre dans le vif du sujet. Il y a
aussi un répertoire imap, d'ailleurs, sur le même serveur.
Et j'ai été très mauvaise langue, car l'exemple fourni là-dessus est
maintenant en C# (ou du moins ça ressemble, j'ai toutefois été surp ris,
en tête de module, de trouver non pas des using, mais des #include <*.h >).
Les moteurs de recherche c'est bien, mais quand on a connu une bonne
adresse, il ne faut pas oublier de revenir y voir :)
Toutefois à présent que j'ai trouvé un traitement qui fonctionne, j e
vais m'y tenir sauf objection de l'auteur. L'aspect extraction en DLL à
appeler aussi bien en WinForm qu'en web ne semble être pris en compte
sur aucune des sources que j'ai consultées (je parle de celles qui
publient leurs sources).
Pour un abord beaucoup plus basique (pour les utilisateurs) on a ceci :
http://www.arobase.org/ecole/pop.htm
Là, on explique clairement à quoi servent les différents protocoles . On
ne se perd pas dans les détails de mise en ½uvre.
http://www.eila.univ-paris-diderot.fr/sysadmin/mail/pop-vs-imap
Apparemment la même cible que ci-dessus, avec des illustrations, et
divers liens vers plus de détails, que je ne suis pas allé voir.
J'y lis ceci, que je serais tenté de moduler :
"Un avantage d'IMAP sur POP est que les messages étant sur le serveur,
vos boîtes sont sauvegardés très régulièrement."
Prudence : en effet, à force de recevoir des mails sur un serveur, un
jour, comme il n'y a plus de place, il faut les enlever. Il n'est pas
forcément clair pour un nouvel utilisateur de ce protocole qu'une fois
un message effacé du serveur, il va s'effacer automatiquement de la
machine qui le lit. Il convient donc, si on souhaite conserver
l'historique de ses mails sur le long terme, d'en réaliser des copies,
en local soit avec des filtres comme on les entend dans Eudora ou
Thunderbird, soit en réalisant une nouvelle réception avec le protoco le
POP. Si on a réalisé ceci avec des filtres d'une application cliente de
messagerie, il faut prendre le temps de vérifier que tous les messages
souhaités ont bien été sauvegardés en local (d'où l'intérêt de pouvoir
en imprimer la liste).
Tout support informatique étant susceptible d'être effacé par exemp le
par fausse man½uvre, il convient de conserver cet historique en
plusieurs exemplaires. Il revient à chacun d'élaborer sa stratégie de
sauvegarde. A l'attention des secrétaires qui ont un jour envoyé des
photocopies de disquettes, ou agrafé l'original à un courrier, ce ser ait
peut-être un jour une bonne idée de rédiger une stratégie de
conservation de mails. Le sujet risque d'être beaucoup moins trivial
qu'il n'y paraît de prime abord.
les 30 premières lignes de quoi ? du corps de l'email ? du cource complet de l'email ?
A ton avis, pour connaître l'expéditeur, le destinataire, la date ?
En réalité, tu pointes là un problème important, même si je ne le prendrai vraiment en compte que plus tard. Si le module doit être conç u pour pouvoir être appelé le plus facilement possible par un dévelop peur, en revanche il semble que ça risque d'être hasardeux de s'en servir sans avoir une petite notion de ce que c'est qu'un message mail, comment il est structuré, émis, transmis, éventuellement filtré (et les d eux sens que peuvent recouvrir ce mot), et reçu.
J'imagine que tout cela fait déjà l'objet de documentations en ligne, une fois que tout fonctionnera et sera en ligne il me restera encore à établir quelques liens vers des pages intéressantes. Si tu veux t'y coller, d'ailleurs, ne te gêne pas ...
A défaut, pour le moment je m'adresse donc à des initiés, à savoi r des développeurs suffisamment intéressés par la réception de mails po ur s'être déjà un peu documentés. C'est vrai que toute information f ournie est susceptible d'élargir la cible, je vais passer quelques minutes là-dessus, après pendant que je développe le module (et que je m'en sers, j'ai déjà une liste de projets sous le coude), si d'autres intervenants ont des pistes intéressantes ça permet de faire avancer le schmilblick.
J'ai retrouvé les pages que j'avais lues sur salemioche.net, ce n'est pas dur on y a mis un lien dessus :
http://www.iprelax.fr/pop/ Intéressant pour les développeurs, on entre dans le vif du sujet. Il y a aussi un répertoire imap, d'ailleurs, sur le même serveur.
Et j'ai été très mauvaise langue, car l'exemple fourni là-dessus est maintenant en C# (ou du moins ça ressemble, j'ai toutefois été surp ris, en tête de module, de trouver non pas des using, mais des #include <*.h >).
Les moteurs de recherche c'est bien, mais quand on a connu une bonne adresse, il ne faut pas oublier de revenir y voir :)
Toutefois à présent que j'ai trouvé un traitement qui fonctionne, j e vais m'y tenir sauf objection de l'auteur. L'aspect extraction en DLL à appeler aussi bien en WinForm qu'en web ne semble être pris en compte sur aucune des sources que j'ai consultées (je parle de celles qui publient leurs sources).
Pour un abord beaucoup plus basique (pour les utilisateurs) on a ceci :
http://www.arobase.org/ecole/pop.htm Là, on explique clairement à quoi servent les différents protocoles . On ne se perd pas dans les détails de mise en ½uvre.
http://www.eila.univ-paris-diderot.fr/sysadmin/mail/pop-vs-imap Apparemment la même cible que ci-dessus, avec des illustrations, et divers liens vers plus de détails, que je ne suis pas allé voir.
J'y lis ceci, que je serais tenté de moduler : "Un avantage d'IMAP sur POP est que les messages étant sur le serveur, vos boîtes sont sauvegardés très régulièrement."
Prudence : en effet, à force de recevoir des mails sur un serveur, un jour, comme il n'y a plus de place, il faut les enlever. Il n'est pas forcément clair pour un nouvel utilisateur de ce protocole qu'une fois un message effacé du serveur, il va s'effacer automatiquement de la machine qui le lit. Il convient donc, si on souhaite conserver l'historique de ses mails sur le long terme, d'en réaliser des copies, en local soit avec des filtres comme on les entend dans Eudora ou Thunderbird, soit en réalisant une nouvelle réception avec le protoco le POP. Si on a réalisé ceci avec des filtres d'une application cliente de messagerie, il faut prendre le temps de vérifier que tous les messages souhaités ont bien été sauvegardés en local (d'où l'intérêt de pouvoir en imprimer la liste).
Tout support informatique étant susceptible d'être effacé par exemp le par fausse man½uvre, il convient de conserver cet historique en plusieurs exemplaires. Il revient à chacun d'élaborer sa stratégie de sauvegarde. A l'attention des secrétaires qui ont un jour envoyé des photocopies de disquettes, ou agrafé l'original à un courrier, ce ser ait peut-être un jour une bonne idée de rédiger une stratégie de conservation de mails. Le sujet risque d'être beaucoup moins trivial qu'il n'y paraît de prime abord.
Jean-Michel Berthier
Bonjour, Non, mais un Google "Csharp IMAP sample" en donne une flopée, par ex : http://www.example-code.com/csharp/imap.asp
"Gloops" a écrit dans le message de news: Jean-Michel Berthier a écrit, le 31/08/2009 09:40 :
Bonjour, S'il n'y a pas grand monde sur le sujet, c'est peut-être parce qu'il y a IMAP ?
Bonjour,
Peut-être, toutefois dans ma recherche je n'ai pas précisé de protocole.
As-tu des exemples en tête ?
Bonjour,
Non, mais un Google "Csharp IMAP sample" en donne une flopée, par ex :
http://www.example-code.com/csharp/imap.asp
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de
news:uBtRCTjKKHA.4820@TK2MSFTNGP02.phx.gbl...
Jean-Michel Berthier a écrit, le 31/08/2009 09:40 :
Bonjour,
S'il n'y a pas grand monde sur le sujet, c'est peut-être parce qu'il y a
IMAP ?
Bonjour,
Peut-être, toutefois dans ma recherche je n'ai pas précisé de protocole.
Jean-Michel Berthier a écrit, le 01/09/2009 09:38 :
Bonjour, Non, mais un Google "Csharp IMAP sample" en donne une flopée, par ex : http://www.example-code.com/csharp/imap.asp
Effectivement. Je jetterai un coup d'il à l'occasion, encore que pou r mes besoins en IMAP j'ai Thunderbird qui est très bien :)
Gloops
Bonjour tout le monde,
Bon, maintenant qu'on a commencé à parler de mails je suppose que ma question sera très bien ici.
Mon logiciel fonctionne très bien, sauf pour la commande (POP) DELE.
Au moment où je veux effacer un message, voilà le programme qui se plante en cherchant à lire la réponse du serveur mail. J'ai cru que l e serveur ne renvoyait rien, qu'il avait pu y avoir un mélange de pinceau x dans l'ordre des commandes qui lui étaient passées, alors j'ai cherch é à lire caractère par caractère, en accédant par ReadByte plutôt que ReadLine, mais peine perdue : d'après la doc j'attends -1 en réponse si il n'y a rien à lire, or comme réponse j'ai perte de contrôle par absence de réponse (la touche F11, au lieu de mettre en jaune la ligne suivante, fait disparaître la couleur jaune du panneau de code source, et puis voilà, et je ne réussis à refaire fonctionner Visual Studio en exécution qu'après l'avoir fait redémarrer ; pareil pour F10).
Voici les objets utilisés : sockServer = new TcpClient(sServer, 110); ns = sockServer.GetStream(); sr = new StreamReader(ns);
Suite à l'échec sur sr.ReadLine() j'ai tenté ns.ReadByte() mais san s davantage de succès.
Au bout d'un certain nombre de tentatives (en redémarrant carrément Visual Studio entre deux sinon le débugueur ne sait pas se débrancher , voir ci-dessous), j'ai ce message : A fatal error has occurred and debugging needs to be terminated. For more details, please see the Microsoft Help and Support Web site. HRESULT=0x80131c08. ErrorCode=0x0
Google ne connaît qu'une page avec ce numéro d'erreur (Pas 0, l'autre avant), et elle est rédigée semble-t-il en Russe. Mon niveau de Russe n'est pas suffisant ;) pour en tirer parti.
Le message invite à faire une recherche sur le site de Microsoft, mais la réponse est fort explicite : Sorry, no results found for: 80131c08
Dans l'outil MSDN c'est plus sophistiqué, puisqu'on a 7 canaux de recherche, alors le nombre de réponses est 0+0+0+0+0+0+0. Bon enfin au bout du compte je crois bien que ça fait 0 quand même.
Lorsque je veux arrêter mon application, m'est répondu : Cannot detach from one or more processes: [5172] WebDev.WebServer.EXE: Operation not supported. Unknown error : 0x80131300. Do you want to terminate them instead?
ça c'est au bout d'un certain nombre de tentatives aussi, car avant, c'est lorsque je cherchais à la démarrer de nouveau qu'on me disait qu'un débugueur était déjà attaché, et qu'on me demandait si je voulais continuer avec (et on me proposait de répondre par oui ou par non, et l a réponse honnête serait : "Pfffp, ben j'sais pô, moé" :) ).
Sur 80131300 Google a 137 réponses, mais la première commence par "Buyers and sellers, find great deals on 80131300" et les suivantes ressemblent, alors je crains fort de ne guère être très avancé. Microsoft ne trouve toujours rien. Ah si quand même chez Google si je mets error devant j'arrive sur une page http://www.lifeasbob.com/Code/ErrorCodes.aspx qui donne une énumération de numéros d'erreurs, dont 80131300 2148733696 CORDBG_E_UNRECOVERABLE_ERROR: Unrecoverable API error . (plus le même site de forum que précédemment en Russe)
C'est déjà ça, mais je crains que ça me laisse un peu sec sur la conduite à tenir.
C'est vrai que les applications exemples que j'ai téléchargées ont fait l'impasse sur l'effacement de messages, donc comme ça on évite de se planter :)
J'ai pensé à un dépassement du temps limite, mais si je traite plus ieurs messages sans les effacer ça se passe bien, donc j'aurais tendance à hésiter à retenir cette piste.
Une idée, quelqu'un ?
Sous Telnet ça se passe bien, le serveur répond tout de suite à la demande d'effacement, avec une ligne qui commence par +OK.
Bonjour tout le monde,
Bon, maintenant qu'on a commencé à parler de mails je suppose que ma
question sera très bien ici.
Mon logiciel fonctionne très bien, sauf pour la commande (POP) DELE.
Au moment où je veux effacer un message, voilà le programme qui se
plante en cherchant à lire la réponse du serveur mail. J'ai cru que l e
serveur ne renvoyait rien, qu'il avait pu y avoir un mélange de pinceau x
dans l'ordre des commandes qui lui étaient passées, alors j'ai cherch é à
lire caractère par caractère, en accédant par ReadByte plutôt que
ReadLine, mais peine perdue : d'après la doc j'attends -1 en réponse si
il n'y a rien à lire, or comme réponse j'ai perte de contrôle par
absence de réponse (la touche F11, au lieu de mettre en jaune la ligne
suivante, fait disparaître la couleur jaune du panneau de code source,
et puis voilà, et je ne réussis à refaire fonctionner Visual Studio en
exécution qu'après l'avoir fait redémarrer ; pareil pour F10).
Voici les objets utilisés :
sockServer = new TcpClient(sServer, 110);
ns = sockServer.GetStream();
sr = new StreamReader(ns);
Suite à l'échec sur sr.ReadLine() j'ai tenté ns.ReadByte() mais san s
davantage de succès.
Au bout d'un certain nombre de tentatives (en redémarrant carrément
Visual Studio entre deux sinon le débugueur ne sait pas se débrancher ,
voir ci-dessous), j'ai ce message :
A fatal error has occurred and debugging needs to be terminated. For
more details, please see the Microsoft Help and Support Web site.
HRESULT=0x80131c08. ErrorCode=0x0
Google ne connaît qu'une page avec ce numéro d'erreur (Pas 0, l'autre
avant), et elle est rédigée semble-t-il en Russe. Mon niveau de Russe
n'est pas suffisant ;) pour en tirer parti.
Le message invite à faire une recherche sur le site de Microsoft, mais
la réponse est fort explicite :
Sorry, no results found for: 80131c08
Dans l'outil MSDN c'est plus sophistiqué, puisqu'on a 7 canaux de
recherche, alors le nombre de réponses est 0+0+0+0+0+0+0.
Bon enfin au bout du compte je crois bien que ça fait 0 quand même.
Lorsque je veux arrêter mon application, m'est répondu :
Cannot detach from one or more processes:
[5172] WebDev.WebServer.EXE: Operation not supported. Unknown error :
0x80131300.
Do you want to terminate them instead?
ça c'est au bout d'un certain nombre de tentatives aussi, car avant,
c'est lorsque je cherchais à la démarrer de nouveau qu'on me disait
qu'un débugueur était déjà attaché, et qu'on me demandait si je voulais
continuer avec (et on me proposait de répondre par oui ou par non, et l a
réponse honnête serait : "Pfffp, ben j'sais pô, moé" :) ).
Sur 80131300 Google a 137 réponses, mais la première commence par
"Buyers and sellers, find great deals on 80131300" et les suivantes
ressemblent, alors je crains fort de ne guère être très avancé.
Microsoft ne trouve toujours rien.
Ah si quand même chez Google si je mets error devant j'arrive sur une
page http://www.lifeasbob.com/Code/ErrorCodes.aspx qui donne une
énumération de numéros d'erreurs, dont
80131300 2148733696 CORDBG_E_UNRECOVERABLE_ERROR: Unrecoverable API error .
(plus le même site de forum que précédemment en Russe)
C'est déjà ça, mais je crains que ça me laisse un peu sec sur la
conduite à tenir.
C'est vrai que les applications exemples que j'ai téléchargées ont fait
l'impasse sur l'effacement de messages, donc comme ça on évite de se
planter :)
J'ai pensé à un dépassement du temps limite, mais si je traite plus ieurs
messages sans les effacer ça se passe bien, donc j'aurais tendance à
hésiter à retenir cette piste.
Une idée, quelqu'un ?
Sous Telnet ça se passe bien, le serveur répond tout de suite à la
demande d'effacement, avec une ligne qui commence par +OK.
Bon, maintenant qu'on a commencé à parler de mails je suppose que ma question sera très bien ici.
Mon logiciel fonctionne très bien, sauf pour la commande (POP) DELE.
Au moment où je veux effacer un message, voilà le programme qui se plante en cherchant à lire la réponse du serveur mail. J'ai cru que l e serveur ne renvoyait rien, qu'il avait pu y avoir un mélange de pinceau x dans l'ordre des commandes qui lui étaient passées, alors j'ai cherch é à lire caractère par caractère, en accédant par ReadByte plutôt que ReadLine, mais peine perdue : d'après la doc j'attends -1 en réponse si il n'y a rien à lire, or comme réponse j'ai perte de contrôle par absence de réponse (la touche F11, au lieu de mettre en jaune la ligne suivante, fait disparaître la couleur jaune du panneau de code source, et puis voilà, et je ne réussis à refaire fonctionner Visual Studio en exécution qu'après l'avoir fait redémarrer ; pareil pour F10).
Voici les objets utilisés : sockServer = new TcpClient(sServer, 110); ns = sockServer.GetStream(); sr = new StreamReader(ns);
Suite à l'échec sur sr.ReadLine() j'ai tenté ns.ReadByte() mais san s davantage de succès.
Au bout d'un certain nombre de tentatives (en redémarrant carrément Visual Studio entre deux sinon le débugueur ne sait pas se débrancher , voir ci-dessous), j'ai ce message : A fatal error has occurred and debugging needs to be terminated. For more details, please see the Microsoft Help and Support Web site. HRESULT=0x80131c08. ErrorCode=0x0
Google ne connaît qu'une page avec ce numéro d'erreur (Pas 0, l'autre avant), et elle est rédigée semble-t-il en Russe. Mon niveau de Russe n'est pas suffisant ;) pour en tirer parti.
Le message invite à faire une recherche sur le site de Microsoft, mais la réponse est fort explicite : Sorry, no results found for: 80131c08
Dans l'outil MSDN c'est plus sophistiqué, puisqu'on a 7 canaux de recherche, alors le nombre de réponses est 0+0+0+0+0+0+0. Bon enfin au bout du compte je crois bien que ça fait 0 quand même.
Lorsque je veux arrêter mon application, m'est répondu : Cannot detach from one or more processes: [5172] WebDev.WebServer.EXE: Operation not supported. Unknown error : 0x80131300. Do you want to terminate them instead?
ça c'est au bout d'un certain nombre de tentatives aussi, car avant, c'est lorsque je cherchais à la démarrer de nouveau qu'on me disait qu'un débugueur était déjà attaché, et qu'on me demandait si je voulais continuer avec (et on me proposait de répondre par oui ou par non, et l a réponse honnête serait : "Pfffp, ben j'sais pô, moé" :) ).
Sur 80131300 Google a 137 réponses, mais la première commence par "Buyers and sellers, find great deals on 80131300" et les suivantes ressemblent, alors je crains fort de ne guère être très avancé. Microsoft ne trouve toujours rien. Ah si quand même chez Google si je mets error devant j'arrive sur une page http://www.lifeasbob.com/Code/ErrorCodes.aspx qui donne une énumération de numéros d'erreurs, dont 80131300 2148733696 CORDBG_E_UNRECOVERABLE_ERROR: Unrecoverable API error . (plus le même site de forum que précédemment en Russe)
C'est déjà ça, mais je crains que ça me laisse un peu sec sur la conduite à tenir.
C'est vrai que les applications exemples que j'ai téléchargées ont fait l'impasse sur l'effacement de messages, donc comme ça on évite de se planter :)
J'ai pensé à un dépassement du temps limite, mais si je traite plus ieurs messages sans les effacer ça se passe bien, donc j'aurais tendance à hésiter à retenir cette piste.
Une idée, quelqu'un ?
Sous Telnet ça se passe bien, le serveur répond tout de suite à la demande d'effacement, avec une ligne qui commence par +OK.
Gloops
Ah au fait, je réalise que si on se met à parler d'erreur d'API, il manque quelques infos :
Microsoft Visual Studio 2005 Version 8.0.50727.762 (SP.050727-7600) Microsoft .NET Framework Version 2.0.50727 SP2
Installed Edition: Professional
Microsoft Visual Basic 2005 77626-009-0005252-41150 Microsoft Visual Basic 2005
Microsoft Visual C# 2005 77626-009-0005252-41150 Microsoft Visual C# 2005
Microsoft Visual C++ 2005 77626-009-0005252-41150 Microsoft Visual C++ 2005
Microsoft Visual J# 2005 77626-009-0005252-41150 Microsoft Visual J# 2005
Microsoft Visual Web Developer 2005 77626-009-0005252-41150 Microsoft Visual Web Developer 2005
Microsoft Web Application Projects 2005 77626-009-0005252-41150 Microsoft Web Application Projects 2005 Version 8.0.50727.762
Crystal Reports AAC60-G0CSA4B-V7000AY Crystal Reports for Visual Studio 2005
Microsoft Visual Studio 2005 Professional Edition - ENU Service Pack 1 (KB926601) This service pack is for Microsoft Visual Studio 2005 Professional Edition - ENU. If you later install a more recent service pack, this service pack will be uninstalled automatically. For more information, visit http://support.microsoft.com/kb/926601
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU (KB937061) This Security Update is for Microsoft Visual Studio 2005 Professional Edition - ENU. If you later install a more recent service pack, this Security Update will be uninstalled automatically. For more information, visit http://support.microsoft.com/kb/937061
Ah au fait, je réalise que si on se met à parler d'erreur d'API, il
manque quelques infos :
Microsoft Visual Studio 2005
Version 8.0.50727.762 (SP.050727-7600)
Microsoft .NET Framework
Version 2.0.50727 SP2
Installed Edition: Professional
Microsoft Visual Basic 2005 77626-009-0005252-41150
Microsoft Visual Basic 2005
Microsoft Visual C# 2005 77626-009-0005252-41150
Microsoft Visual C# 2005
Microsoft Visual C++ 2005 77626-009-0005252-41150
Microsoft Visual C++ 2005
Microsoft Visual J# 2005 77626-009-0005252-41150
Microsoft Visual J# 2005
Microsoft Visual Web Developer 2005 77626-009-0005252-41150
Microsoft Visual Web Developer 2005
Microsoft Web Application Projects 2005 77626-009-0005252-41150
Microsoft Web Application Projects 2005
Version 8.0.50727.762
Crystal Reports AAC60-G0CSA4B-V7000AY
Crystal Reports for Visual Studio 2005
Microsoft Visual Studio 2005 Professional Edition - ENU Service Pack 1
(KB926601)
This service pack is for Microsoft Visual Studio 2005 Professional
Edition - ENU.
If you later install a more recent service pack, this service pack will
be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/926601
Security Update for Microsoft Visual Studio 2005 Professional Edition -
ENU (KB937061)
This Security Update is for Microsoft Visual Studio 2005 Professional
Edition - ENU.
If you later install a more recent service pack, this Security Update
will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/937061
Ah au fait, je réalise que si on se met à parler d'erreur d'API, il manque quelques infos :
Microsoft Visual Studio 2005 Version 8.0.50727.762 (SP.050727-7600) Microsoft .NET Framework Version 2.0.50727 SP2
Installed Edition: Professional
Microsoft Visual Basic 2005 77626-009-0005252-41150 Microsoft Visual Basic 2005
Microsoft Visual C# 2005 77626-009-0005252-41150 Microsoft Visual C# 2005
Microsoft Visual C++ 2005 77626-009-0005252-41150 Microsoft Visual C++ 2005
Microsoft Visual J# 2005 77626-009-0005252-41150 Microsoft Visual J# 2005
Microsoft Visual Web Developer 2005 77626-009-0005252-41150 Microsoft Visual Web Developer 2005
Microsoft Web Application Projects 2005 77626-009-0005252-41150 Microsoft Web Application Projects 2005 Version 8.0.50727.762
Crystal Reports AAC60-G0CSA4B-V7000AY Crystal Reports for Visual Studio 2005
Microsoft Visual Studio 2005 Professional Edition - ENU Service Pack 1 (KB926601) This service pack is for Microsoft Visual Studio 2005 Professional Edition - ENU. If you later install a more recent service pack, this service pack will be uninstalled automatically. For more information, visit http://support.microsoft.com/kb/926601
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU (KB937061) This Security Update is for Microsoft Visual Studio 2005 Professional Edition - ENU. If you later install a more recent service pack, this Security Update will be uninstalled automatically. For more information, visit http://support.microsoft.com/kb/937061
Gloops
Gloops a écrit, le 31/08/2009 15:59 :
Et j'ai été très mauvaise langue, car l'exemple fourni là-dessu s est maintenant en C# (ou du moins ça ressemble, j'ai toutefois été su rpris, en tête de module, de trouver non pas des using, mais des #include <* .h>).
En fait ça va peut-être venir, puisque sur la page de garde on mentio nne C# (d'où mon zèle à prendre mes désirs pour des réalités peut -être), mais on mentionne aussi C et Java.
Sous #include <*.h> on trouve des printf(), je pense que j'ai plutôt vu un exemple en C.
Gloops a écrit, le 31/08/2009 15:59 :
Et j'ai été très mauvaise langue, car l'exemple fourni là-dessu s est
maintenant en C# (ou du moins ça ressemble, j'ai toutefois été su rpris,
en tête de module, de trouver non pas des using, mais des #include <* .h>).
En fait ça va peut-être venir, puisque sur la page de garde on mentio nne
C# (d'où mon zèle à prendre mes désirs pour des réalités peut -être),
mais on mentionne aussi C et Java.
Sous #include <*.h> on trouve des printf(), je pense que j'ai plutôt vu
un exemple en C.
Et j'ai été très mauvaise langue, car l'exemple fourni là-dessu s est maintenant en C# (ou du moins ça ressemble, j'ai toutefois été su rpris, en tête de module, de trouver non pas des using, mais des #include <* .h>).
En fait ça va peut-être venir, puisque sur la page de garde on mentio nne C# (d'où mon zèle à prendre mes désirs pour des réalités peut -être), mais on mentionne aussi C et Java.
Sous #include <*.h> on trouve des printf(), je pense que j'ai plutôt vu un exemple en C.
