>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.
Hello Ron,
from the top of my head (could be wrong for the TagMsg):
procedure FreeAndNil(var Obj: TObject);
begin
Obj.Free;
Obj := nil;
end;
LongWord is a Cardinal
TagMsg is TMessage
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
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
On Dec 6, 2007, at 04:36, Wilfried Mestdagh wrote:
> from the top of my head (could be wrong for the TagMsg):
>
> procedure FreeAndNil(var Obj: TObject);
> begin
> Obj.Free;
> Obj := nil;
> end;
>
> LongWord is a Cardinal
> TagMsg is TMessage
I don't know in D2, but in D5+ TMessage is
On Dec 6, 2007, at 04:36, Wilfried Mestdagh wrote:
> procedure FreeAndNil(var Obj: TObject);
> begin
> Obj.Free;
> Obj := nil;
> end;
begin
if (Obj <> Nil) Then
Obj.Free;
Obj := Nil;
End;
> LongWord is a Cardinal
This is correct.
dZ.
--
To uns
> > 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
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
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
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
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
Hello Arno Garrels,
thank you for your prompt answer.
The exception 'WSAAsyncSelect 10022 Invalid Argument' is fired at the line
below:
procedure TCustomWSocket.Connect;
...
FSelectEvent := FD_READ or FD_WRITE or FD_CLOSE or
FD_ACCEPT or FD_CONNECT;
iStatus :=
[EMAIL PROTECTED] wrote:
> Hello Arno Garrels,
> thank you for your prompt answer.
>
> The exception 'WSAAsyncSelect 10022 Invalid Argument' is fired at the
> line below:
>
> procedure TCustomWSocket.Connect;
> ...
> FSelectEvent := FD_READ or FD_WRITE or FD_CLOSE or
>
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
Wilfried,
>
>> 3. Put a loop in my DataAvailable event that will do a Receive until I
>> get -1 back. This would probably be the easiest to implement for me.
>
> No never do that. Don't set wsoReceiveLoop. If something is still (or
> again) in receiving winsock buffer when you leave OnDataAvail
[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:
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:
> 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
Jake Traynham wrote:
> Wilfried,
>
>>
>>> 3. Put a loop in my DataAvailable event that will do a Receive
>>> until I get -1 back. This would probably be the easiest to
>>> implement for me.
>>
>> No never do that. Don't set wsoReceiveLoop. If something is still (or
>> again) in receiving winso
If the Faststream FTP server uses the ICS FTP component, why does the
MLST command return a zero file size and . instead of the name for a file
that exists, and fails to calculate an MD5Sum?
> MLST client-toolkit-4.11.8-windows.jar
<
size=0;type=file;perm=fdrwa;create=20051108192400;modify=2007120
Hello,
Firstly, it is "Fastream" not "faststream". Second, we will investigate the
issue tomorrow. The probable reason would be we use a custom unit since we
need to support multi-cores/threads. WE also must support deep user
permission settings (See "perm=fdrwa;").
Thanks a lot for the report,
Hello,
Fixed the bug in my copy. Thanks,
SZ
On Thu, 6 Dec 2007 20:04 + (GMT Standard Time), Angus Robertson -
Magenta Systems Ltd <[EMAIL PROTECTED]> wrote:
>
> If the Faststream FTP server uses the ICS FTP component, why does the
> MLST command return a zero file size and . instead of the
21 matches
Mail list logo
