Hi Remy - I appreciate your help!
I'll get to the points you raised below ..
>> If I can use AThread.Data to recognise users, how is simply
>> identifying the AThread bad?
>
> Using the thread pointer itself as an
> identifier is bad. Using the members of the thread object is not
> (except of the the ThreadID, that is).
Not quite clear on what your saying here... excuse me sounding dumb, but can
you simplify that a bit!?
They way I was doing things, was like this:
//Declare the T stuff here
type
TConnection = class(TObject)
Key, IP: String;
Thread: TIdPeerThread;
end;
type
TUser = record
UserName,
Password,
Email,
Session: String;
Connection: TConnection;
end;
Public
Users: Array of TUser;
//When client connects (and has logon info verified)
Users[Length(Users) -1].Connection.Thread := AThread;
//When needing to identify user
For I to Length(Users) -1 do
Begin
If Users[I].Connection.Thread = AThread then
Begin
UserName := Users[I].UserName;
End;
End;
//When writing to the client...
TIdPeerThread(Users[I].Connection.Thread).Connection.WriteLn(TheMessage);
I'd seen the above method of addressing the AThread used in one of the old
Indy 8 demo's by: Jeremy Darling (though admittedly he also used
Threads.Locklist and client objects which doesn't work for me because I need
to track ALL online AND offline users in the same place - EG an array. The
IdTCPServer threadlist of course only contains those active connections
which is why I have avoided using it.
> The Data property is only valid for the lifetime of the connection.
> When a client disconnects, regardless of whether the thread is being
> pooled or not, the thread still cleans up after itself, including
> freeing any object that is currently assigned to the Data property.
> That way, each client starts with a blank slate if the thread was
> obtained from a pool.
Righto, so basically it's self cleaning when connection is disconnected..
>> Data is a Property of the AThread so presumably (correct me if I am
>> wrong) it would still identify the very exact same thread/property
> which
>> ever I use to identify my users?
>
> No, it would not. You would assign a different object to the Data
> property each time a new client connects, and then remove/free the
> object when the client disconnects.
Yes, but why is that better than simply using the method above to match the
AThread with a TIdPeerThread ? - I still don't really see why I must use the
data object - I'm not trying to associate the thread with an object, more
like keep a record of which user is associated with which thread. As stated
above, sorry if this makes me sound really stupid, but if I don't ask I
won't know!
>> I did once look at using a TList and the Threads.LockList thing but
> I had
>> a problem in that I also needed to keep track of offline clients in
> the same
>> place
>
> Thee is no problem doing that. Simply include a flag for each item
> that indicates whether the client is connected or not.
Yes, I agree with that.. Well I in a way doing that because when the user
logs off/loses connectivity (connection tester also in development) then the
Users[I].Connection (Connection: TConnection as shown above) will simply be
set to nil. Doing that I can then simply use something like:
IF Users[I].Connection <> nil then
begin
//Do online stuff here
end;
> A better idea for what exactly? What are you trying to track in the
> first place?
Well I'm basically just trying to keep all my users (both on and offline) in
one place - A dynamic array. All I want to do is store the AThread that each
user is using in their connection record in the array. I know it might not
be the best, or quickest way of identifying users but I just want something
that is simple to understand (from my POV) and easy to use. Not really keen
on playing with AThread.Data property to be honest!
Thanks for your help !
