>> antifreeze doesn't. period.
>TIdAntiFreeze has always been a bastardized component, even in older
>versions of Indy. You should avoud TIdAntiFreeze whenever possible, even in
>older versions.
Antifreeze worked in Indy 9. Does not in Indy 10.
>You should have been using threads to begin with.
The more complex you make the plumbing the easier it is to stop
up the drain. I have no need for threads. I'm not doing
multiple things here. I'm making one POP connection,
downloading and making one SMTP connection and uploading. If
the antifreeze in 10 would work as it should, I could drop one
little component on the form, activate it and problem solved.
Compare that to the bottle of aspirin needed for me to deal with
threads and it's not a difficult choice.
>> Next. Stupid things... like the smtp component not disconnecting
>properly.
>
>What makes you think that?
>
>> Here's my code:
>
>Use this code instead:
>
Did that, still bombing. Modified it:
log('SMTP', 'Sending: ' + MailMessage.Subject + To: ' +MailMessage.Recipients.EMailAddresses, Form1);
SMTPClient.Connect;
try
log('SMTP','Client connected',form1);
SMTPClient.Send(MailMessage);
log('SMTP','Message Sent',form1);
Inc(msgssent);
finally
SMTPClient.Disconnect;
end;
Never gets to 'Client connected' It claims that the server is
disconnecting while the program is still trying to send. It's
probably something ignorant like a password problem. But, since
I can't see the actual output from the SMTP server, and the only
response Indy gives me is 'gracefully disconnected', I don't
have a clue.
>No, that was your fault, not Indy's. You should not have been using the
>OnDisconnect event to disconnect and free the sockets. That was just plain
>wrong, in any version of Indy.
My formal computer education consists of a Pascal course on the
DEC10 in 1982. To me, a try/except is just a glorified
if/then. My code may have not been pretty, but it worked in
Indy 9.
>> The only reason I even went through the agony of installing indy 10 and
>> rewriting my code was so I could put 'inline' 'text/plain' message parts
>in
>> the message.
>
>Why do you think that Indy 10 cannot do it? Indy 10's message handling is
>vastly more complete than Indy 9's is.
Thanks, I'll try that, as soon as I can get the software sending mail again.
>> You would think that those writing the Indy code would give me a
>> messagepart.contentdisposition string in tidtext like they do with
>tidattachment.
>
>Why, though? There is no reason to declare text as 'inline' - it is already
>inlined by its very nature. Why do you need 'Content-Disposition: inline'
>for text?
If you want to display text after an HTML part you have to put
that 'inline' in there, otherwise, the email client doesn't
display it. Hence, when AVG scans an email, it inserts a tag as
such:
-------------------------------1143221539--
--=======AVGMAIL-44283FC07536=======
Content-Type: text/plain; x-avg=cert; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Description: "AVG certification"
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.6/287 - Release Date: 3/21/2006
--=======AVGMAIL-44283FC07536=======--
The best I've come up with is that 'inline' guarantees that
messagepart will be shown regardless of how many other
messageparts exist.
>TIdAttachmentMemory has a DataStream property. You can save the TStringList
>to that TStream, either directly or via the
>TIdAttachment.PrepareTempStream() method.
>
>Alternatively, TIdAttachmentMemory accepts a String as a parameter to its
>constructor. You can pass the TStringList's Text property as that value.
>
>Alternatively, you can write your own TIdAttachment-derived class that holds
>a TStringList internally. One of the new features in Indy 10 is that the
>TIdAttachment architecture is no longer locked down to files only.
>TIdAttachment is an abstract base that that user-defined classes can be
>derived from now. Indy just happens to provide TIdAttachmentMemory and an
>alternative to TIdAttachmentFile, but you are not required to use it if it
>does not suit your needs.
>
Sounds like a lot of work. I classify streams right up there
with threads and pointers. Great if you wanna shave off a few
picoseconds, a pain in the ass when it just doesn't matter.
>> those connects and disconnects. Worked in Indy 9. Crap in Indy 10.
>
>If it is working in TIdPOP3, then it is guaranteed to work in every other
>component as well, including TIdSMTP. They all send their data to the same
>place, which is where the Intercept is implemented. It is not possible for
>any Indy component to send outgoing data, or receive incoming data, without
>that data going through the Intercept system.
If what you say is true, then for some reason, the Indy group
decided that nobody needs to see the actual communications with
the SMTP server anymore. You saw exactly what I get.
>Indy works just fine with GMail. Many users have reported that they have
>been able to use Indy with GMail without problems. And the latest Indy 10
>snapshot has full support for the standard OpenSSL DLLS now, so the SSL
>support is even more stable.
>
Yes, I am connecting and was sending through G-mail (until I
'upgraded'). However, the fact is that I've had to reinstall
Delphi due to a screwed-up Indy install, spend hours rooting out
old Indy 9 code scattered everywhere, download a working copy
of Indy 10, (1.15 still gives me a corrupt download), install it
and rewrite the program to use Indy 10 instead of 9, learn Indy
from scratch and SSL from scratch... all to satisfy Google's
paranoia. Whereas, if ICS, which I've used for years, had SSL
for POP and SMTP or if I had said the hell with Google (smite me
now daytraders) I would have been done a month ago and with lot
less coding.
Thanks for the advice but from what I've seen of the SMTP and
Antifreeze units, Indy 10, compared with 9... is crap.
