"twistedvoid" <postmaster@twistedvoid.com> wrote in message
news:44293972$1@newsgroups.borland.com...
> 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.
TIdAntiFreeze works the same in Indy 10 that it did in Indy 9.
> Did that, still bombing.
You need to be more specific. You haven't provided ANY details about what
EXACTLY is hanppening.
> SMTPClient.Connect;
> try
> log('SMTP','Client connected',form1);
<snip>
> Never gets to 'Client connected'
The only way that can happen is if the socket is not actually connecting to
the server at all. Did you set the ConnectTimeout property to a
non-infinite value? Did you verify that you are specify a valid Host and
Port for the server?
Incidently, you were using the OnDisconnect event earlier. Are you using
the OnConnect event as well? If so, what does that code look like?
OnConnect is triggered after the underlying socket connects to the server
socket, but before TIdSMTP actually negotiates the login with the server.
So, if you are doing anything with the socket inside that event, you could
be screwing up the data exchange, such that Connect() hangs waiting for data
that it never receives because you received in your own code.
> It claims that the server is disconnecting while the program is still
trying to send.
But your code is not sending anything at all if Connect() is not succeeding.
> It's probably something ignorant like a password problem.
If that were the case, then Connect() would be throwing an exception when
the server reports a login error.
> 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.
Hardly. You need to brush up on what exception handling is actually about.
It is much more complex then a simple if/then, and much more flexible.
Indy's architecture relies heavily on exceptions.
> My code may have not been pretty, but it worked in Indy 9.
Only by a fluke on your part. Then code you showed was not effecient even
for Indy 9.
> 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:
Fair enough. Like I said earlier, the TIdMessagePart.ExtraHeaders property
can be used for that.
> The best I've come up with is that 'inline' guarantees that
> messagepart will be shown regardless of how many other
> messageparts exist.
The formal defination of the 'Content-Disposition' header is defined in RFC
2183:
Communicating Presentation Information in Internet Messages: The
Content-Disposition Header Field
http://www.ietf.org/rfc/rfc2183.txt
> 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.
All the more reason to write your own TIdAttachment-derived class to do what
you need. Look at TIdAttachmentFile.pas and TIdAttachmentMemory.pas to see
how they are implemented.
> 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 completely missed the point I was making. *ALL* Indy traffic, both
inbound and outbound, goes through the Intercept system. There is no way
that TIdSMTP can be sending data to the SMTP server without the Intercept
system seeing it. Thus, the TIdLog components must be able to log *ALL*
data that Indy exchanges, regardless of the component being used.
Everything that Indy sends ultimately goes through
TIdIOHandler.WriteDirect(), which is where the Intercept for outbound data
is invoked. The only place that receives data from the connection directly
is in TIdIOHandlerStack.ReadFromSource(), which is where the Intercept for
inbound data is invoked. What you describe is simply not possible. And if,
by some chance, it were possible, it would have been seen and addressed a
long time ago.
> However, the fact is that I've had to reinstall Delphi due to a screwed-up
Indy install
... to which you still have not provided any details ...
> learn Indy from scratch and SSL from scratch...
You do not need to re-learn Indy or SSL from scratch in order to migrate
from 9 to 10.
Gambit
