[EMAIL PROTECTED] wrote:
> Quote from Arno:
> csDestroying is already in the states when you call
> DisconnectAll() from the destructor of the server's
> owner component.
> If you created the server with a nil owner, no problemo.
> -
>
> Then, as you say, there's no problemo, because that
Quote from Arno:
csDestroying is already in the states when you call
DisconnectAll() from the destructor of the server's
owner component.
If you created the server with a nil owner, no problemo.
-
Then, as you say, there's no problemo, because that's
exactly what I do. :)
So, to make su
[EMAIL PROTECTED] wrote:
> Quote from Arno:
> I guess it's worth a trial to simply ThreadAttach all
> clients in
> the destructor after all threads terminated.
> ..
>
>
> I'm sorry, I don't mean to be obtuse, but what would
> that do?
That creates a new hidden window in the new, current
Quote from Arno:
Not in my sources. It posts a message to tell the
threads that they
shall terminate. When a thread terminates clients are
just ThreadDetached.
Yes, you are right, sorry.
Quote from Arno:
I guess it's worth a trial to simply ThreadAttach all
clients in
the destruct
DZ-Jay wrote:
> On Dec 6, 2007, at 05:39, Arno Garrels wrote:
>
>> I think it helps to disconnect all, then destroy the server
>> object after all clients have been actually disconnected.
>
> I'll look into this, but as far as I recall (I have no access to the
> source code right now), the TWSock
On Dec 6, 2007, at 05:39, Arno Garrels wrote:
> I think it helps to disconnect all, then destroy the server
> object after all clients have been actually disconnected.
I'll look into this, but as far as I recall (I have no access to the
source code right now), the TWSocketThrdServer destructor
On Dec 6, 2007, at 05:29, Francois Piette wrote:
> Make sure all connections are closed/aborted before freeing the server
> object.
According to the TWSocketThrdServer code, this is what it does in its
destructor...
> And as usual, at the application level don't store a reference to a
> connec
DZ-Jay wrote:
> On Dec 6, 2007, at 04:28, Francois Piette wrote:
>
>> For some reason, you call PutDataInSendBuffer after it has already
>> been freed.
>
> After the object was freed, or the buffer was freed?
The buffer is freed in the destructor of TCustomWSocket.
> Keep in mind
> that I jus
> > For some reason, you call PutDataInSendBuffer after it has already been
> > freed.
>
> After the object was freed, or the buffer was freed? Keep in mind that
> I just called WSocketThrdServer.Free, so it was problably destroying
> the object while it was attempting to send...?
I think freeing
On Dec 6, 2007, at 04:28, Francois Piette wrote:
> For some reason, you call PutDataInSendBuffer after it has already been
> freed.
After the object was freed, or the buffer was freed? Keep in mind that
I just called WSocketThrdServer.Free, so it was problably destroying
the object while it w
>The full error is "[EAccessViolation] Access
> violation at address 00469094 in module
> 'SmailQ_con.exe'. Read of address 0008"
> { THE FOLLOWING LINE }
> if FBufList.Count = 0 then begin
It is likely that FBufList is already freed and nilled when the line is
executed.
11 matches
Mail list logo
