🚀 go-pugleaf

"Dennis Jones" <nospam@nospam.com> wrote in message
news:45b95649$1@newsgroups.borland.com...

> Remy, must you always ask *why* someone is doing something?

Yes.  Because it gets people thinking about what they are trying to
do.  Many times, they are taking the wrong approach with something, or
doing something wrong that they shouldn't be doing.  Case in point -
you.  You should not be calling Connected() while Connect() is still
running.  Nothing should be trying to access the connection in any way
while Connect() is still running.  Indy is not designed for that
particular operation.

> Can't you just answer the question without questioning the motive
behind it?

No. Because the motives tend to be incorrect more times than not.  And
besides, knowing what the motivation is behind something offers better
chances at providing alternative suggestions that the person may not
have even considered yet.

> Since it is apparently not obvious why someone would want to do
> what I am doing

The fact you are trying to call Connected() while Connect() is still
running tells me right away that you are misusing Indy in a way that
it was not designed for.  If you don't want to learn the proper way to
use it, then that is your choice.  Other people may not know how to
use it correctly, which is why they get into trouble and not
understand when something doesn't work correctly.  Hense the desire to
know what they are trying to do so they can be pointed in the right
direction.

> consider how you would indicate the current state of a volatile
connection.

There is no way to determine the current state while the socket is
still in a volatile condition - hense the term volatile, meaning
"unstable, unsettled" according to the dictionary.  So in your own
code, you would set a flag or a UI display or whatever to "connecting"
before actually calling Connect(), and then wait for Connect() to exit
before doing anything else with the connection.  That is the true
state of the connection anyway, and there is no way to query that
state once the connection attempt begins running, as it can change at
any moment.  You have to wait until Connect() either fully succeeds or
fully fails.  There is no in-between.

> When the connection is up, you want to indicate a "Connected"
status;
> when it is not, you want to indicate a "Not connected" status.

Which is exactly what Connected() does - EXCEPT when Connect() is
still running because the state is not known at the moment Connected()
is called.

> It should be obvious that it would be ridiculous to indicate
"Connected"
> during those few moments when it is trying to establish a connection

If you read the documentation for Connected(), it says exactly under
which conditions Connected() returns True.  Those conditions are met
while the socket is in the process of establishing a connection.  If
you don't like it, then don't call Connected() while Connect() is
running.

> 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.

That thread has no business querying the connection until after
Connect() has been called and exited one way or the other.  During
that time, the connection state is unstable, so of course the result
of Connected() will be questionable during that time.

> To force queries of the Connected property to occur only after a
> Connect()/Disconnect() call have completed is just plain silly

No, it is not silly.  And I did not say that Connected() could not be
called before Connect() or after Disconnect().  Only that it can't be
called DURING Connect().

> not to mention that it would require unnecessary synchronization and
> coupling between the threads.

A large part of multi-threaded programming is about synchronizing the
threads to each other.  The OS sync objects are very light-weight and
efficient in that matter.  Just because you may not like doing it does
not make it wrong.  You always have to synchronize access to shared
resources to ensure there state across thread boundaries.  That is
proper programing practice when threads are involved.

> Who is to say that I am calling them out of order?

I am.  Knowing Indy inside and out like I do, I know exactly how and
when Connect() and Connected() work.  Connected() is not reliable
while Connect() is still running, because the socket state is not
settled yet.

> The Connected property should *not* be dependent on *when* it is
called.

Yes, it should.  There are a lot of things going on inside of Indy's
internals.  Connected() is dependant on a number of internal object
states.  Those states are subject to change while Connect() is
running.

> If it is, then it should be documented that way -- but it is not.

Yes, it is.

> When the connection has been properly established, then AND
> ONLY THEN, should Connected be true.  Any other behavior is wrong.

If you don't like it, then you are welcome to join the Indy team and
change it to your liking.  Indy is open-source, afterall.


Gambit