🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.internet.socket
Article #1473

Re: IdTCPClient Connected question

#1473
From: Dennis Jones
Date: Fri, 26 Jan 2007 01:16
51 lines
3532 bytes
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:45b938e2$1@newsgroups.borland.com...

> Besides, you shouldn't be calling Connected() until Connect() exits
> anyway.

Who says?  Is that documented somewhere?


> Why are you doing that?

Remy, must you always ask *why* someone is doing something?  Can't you just 
answer the question without questioning the motive behind it?  Not only is 
it annoying and occasionally rude, but it is also very condescending toward 
the person who is asking the question; and in point of fact, is largely 
irrelevant much of the time.  If you must know the answer before you can 
give the person an appropriatate answer, then please try to phrase your 
question so that it does not imply that the person is an idiot.

Since it is apparently not obvious why someone would want to do what I am 
doing, consider how you would indicate the current state of a volatile 
connection.  When the connection is up, you want to indicate a "Connected" 
status; when it is not, you want to indicate a "Not connected" status.  It 
should be obvious that it would be ridiculous to indicate "Connected" during 
those few moments when it is trying to establish a connection and then 
change back to "Not connected" after it fails ("Connecting" would be more 
appropriate).  The same is true for IdTCPClient, but requirements and 
expectations for a library like Indy are much stronger and more explicit --  
so to state that it is connected when it is not is just plain wrong.

In my case, the state of the connection is queried in a thread that is 
separate from that which is actually attempting to establish the connection. 
To force queries of the Connected property to occur only after a 
Connect()/Disconnect() call have completed is just plain silly -- not to 
mention that it would require unnecessary synchronization and coupling 
between the threads.


>> How can I determine the *true* state of the client?
>
> Stop calling methods out of order.

Who is to say that I am calling them out of order?  The Connected property 
should *not* be dependent on *when* it is called.  If it is, then it should 
be documented that way -- but it is not.  If a connection has not been 
properly established, then Connected should be false -- it's that simple. 
When the connection has been properly established, then AND ONLY THEN, 
should Connected be true.  Any other behavior is wrong.

- Dennis 
Technical Details
Message-ID: <45b95649$1@newsgroups.borland.com>
Path: arc1-ca.pugleaf.net!g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.albasani.net!feeder06.uucp-net.de!reader.uucp.at!feeder02.uucp.at!feeder08.uucp.at!news.uucp.at!newsgroups.borland.com!not-for-mail
References: <45b9274f@newsgroups.borland.com> <45b938e2$1@newsgroups.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 11508e,e8cbc2087e955870
X-Google-Attributes: gid11508e,public
X-Google-Language: ENGLISH,ASCII-7-bit
From: "Dennis Jones" <nospam@nospam.com>
Newsgroups: borland.public.cppbuilder.internet.socket
References: <45b9274f@newsgroups.borland.com> <45b938e2$1@newsgroups.borland.com>
Subject: Re: IdTCPClient Connected question
Date: Thu, 25 Jan 2007 17:16:41 -0800
Lines: 53
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: 71.245.109.58
Message-ID: <45b95649$1@newsgroups.borland.com>
X-Trace: newsgroups.borland.com 1169774153 71.245.109.58 (25 Jan 2007 17:15:53 -0800)
Path: arc1-ca.pugleaf.net!g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.albasani.net!feeder06.uucp-net.de!reader.uucp.at!feeder02.uucp.at!feeder08.uucp.at!news.uucp.at!newsgroups.borland.com!not-for-mail