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
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,
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
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
[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
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
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
[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
>
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 :=
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: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
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: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
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
>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.
21 matches
Mail list logo
