"Michael Stieler" <michael.stieler@rie.eu> wrote in message
news:478f3892@newsgroups.borland.com...
> As for the build number, I dont't know where to look for this.
Right-click on any Indy component in the form designer.
> The latest entry in IdTcpClient is
> Rev 1.38 1/15/05 2:14:58 PM
> made by you.
That is not helpful. The change history that is recorded in each source
file no longer applies. It was created by TeamCoherence, a version control
system that Indy hasn't used for a long while now. Indy made the switch to
StarTeam awhile back, and StarTeam does not record change history in the
source code directly like TeamCoherence did.
> The problem is, that IOHandler is nil at this point
Well, that would certainly explain the AV, but the real problem is that it
shouldn't be nil at that point. You already showed why - TIdTCPClient
created an IOHandler object internally if one doesn't already exist. So
this goes back to my earlier idea that you are not using the TIdTCPClient
correctly in your own threading code. You are probably doing something in
your worker thread that indirectly destroys the IOHandler while Connect() is
still trying to initialize it.
> This is what I was thinking about. Connect() blocks until success
> or failure, so my poll thread couldn't call during this time.
Why is your polling thread even running at all while the client is still
trying to connect to the server? There is nothing to poll yet. Why are you
trying to poll and connect at the same time? Don't do that. Connect fully
first, then start polling if the connection succeeded.
> I rember hearing about a (performance?) problem with calling
> conn.Connected, so I used my own status variable for this. Wrong?
Yes. You don't need a separate variable for that.
Gambit
