"twistedvoid" <postmaster@twistedvoid.com> wrote in message
news:4428dd51$1@newsgroups.borland.com...
> After spending hours cleaning up the mess the 'install program' made
What "mess" are you referring to?
> I finally got the latest release of Indy 10 installed only to find that
things
> that worked with indy 9, simple things mind you, are causing me major
> headaches with indy 10.
Such as?
> 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.
> I know damn well it isn't my code causing the freezups and I don't have
> the time to rip out 1000 lines of code that would work fine if antifreeze
> worked and rearrange it into threads.
You should have been using threads to begin with.
> Next. Stupid things... like the smtp component not disconnecting
properly.
What makes you think that?
> Here's my code:
Use this code instead:
procedure Tform1.dosmtpconnect(ASender: TOobject);
begin
Application.ProcessMessages;
try
try
log('SMTP', 'Sending: ' + MailMessage.Subject + ' To: ' +
MailMessage.Recipients.EMailAddresses, Form1);
SMTPClient.Connect;
try
SMTPClient.Send(MailMessage);
Inc(msgssent);
finally
SMTPClient.Disconnect;
end;
finally
sendingmail := False;
FreeAndNil(SMTPClient);
if configform.sslcheckbox.Checked then
FreeAndNil(smtpsslsocket);
end;
smtperror := False;
except
on E: Exception do
begin
smtperror := True;
log('SMTP', 'ERROR: ' + E.Message, Form1);
end;
end;
end;
> Seems simple enough. But, I had to put the smtpondisconnect routines
> into the try/except blocks because Indy, in some wisdom beyond mine,
> is disconnecting the smtp somewhere in the middle of disconnecting
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.
> next thing, intuitive shit that should work doesn't...
Such as?
> 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.
You did not need Indy 10 for that.
> Stupid me for thinking Indy 10 could do it when Indy 9 couldn't.
Why do you think that Indy 10 cannot do it? Indy 10's message handling is
vastly more complete than Indy 9's is.
> You would think that the headers.add would add a header line in that
> messagepart. I thot so. It doesn't.
You need to add custom headers to the ExtraHeaders property, not the Headers
property. The Headers property is only for those values that provide the
backend for the cooresponding TIdMessagePart, TIdText, and TIdAttachment
properties. Everything else is Extra.
> 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?
> Yes, I tried using tidattachment. Damned if I can figure a way to assign
a
> string list as the body of a tidattachment, there's no tidattachment.body
to
> assign it to.
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.
> Forget tidattachmentfile.
See above.
> And while I'm ranting: The tidlogfile with the smtp component has ceased
to be of use.
And your actual problem is ... ? Please be more specific.
> Damned useful. And I know e-mail was being sent and recieved in the midst
of
> 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.
> The only reason I started using Indy and became a traitor to ICS was
because
> I needed SSL and I didn't have years to wait for the ICS crew to get
around to
> writing SSL for the pop and smtp components and then, wait another year
for
> them to release it to the public. Now I'm regretting my decision. I
should have
> just told my customers to stay the hell away from g-mail and use a less
paranoid
> POP/SMTP server so that I could use a less screwed up POP/SMTP component
> set.
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.
Gambit
