Re: [twsocket] DesignIde70.bpl dependancy
Francois Piette wrote: >> Why is there a dependency on designide70.bpl if used with D7? > > There is a property editor. AFAIK designide is not a legal redistributable. It's very easy to split current package into a designtime and a runtime package. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Error 334
kaythorn wrote: > What is error 334? Authentication AUTH PLAIN failed, use AUTH LOGIN instead, for the exact meaning of error code 334 search the RFC. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Error 334
On running the AllInOne function in Mailsnd1 I got the following result: Connecting to SMTP server... 220 smtp001.apm-internet.net ESMTP < 220 smtp001.apm-internet.net ESMTP RequestDone Rq=0 Error=0 EHLO Kaythorn > EHLO Kaythorn 250-smtp001.apm-internet.net < 250-smtp001.apm-internet.net 250-AUTH=LOGIN < 250-AUTH=LOGIN 250-AUTH LOGIN < 250-AUTH LOGIN 250-PIPELINING < 250-PIPELINING 250 8BITMIME < 250 8BITMIME RequestDone Rq=10 Error=0 AUTH PLAIN bWFpbEBrYXl0aG9ybi5jby51awBtYWlsQGtheXRob3JuLmNvLnVrAGZyejExMg== > AUTH PLAIN bWFpbEBrYXl0aG9ybi5jby51awBtYWlsQGtheXRob3JuLmNvLnVrAGZyejExMg== 334 UGFzc3dvcmQ6 < 334 UGFzc3dvcmQ6 RequestDone Rq=11 Error=334 UGFzc3dvcmQ6 Error, stoped All-In-One demo What is error 334? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
Arnold FLUTEAUX wrote:
> If I understand well what you say, in may case, when I cut off
> voluntarily the connection from server side, the datasocket must be
> closed and the Connected property must be True. Is that ?
The order in which both connections are closed determines the
server, it may be the other way around, who knows?
> What I don't understand is :
> -if I launch a quitAsync => I've FTP Component not connected.
> And if I laucn connectAsync, I've "Ftp already connected"
> -or if I'm waiting 2 or 3 seconds after cut of the connection,
> Connected property set to false
> In fact, I'm sorry but I don't understand.
>
> So in the case where there is a problem on the line and there is a
> brutal disconnection, what can I test to know if I must launch a
> reconnection without waiting for 2 or 3 seconds ?
Let's play with the FtpTst demo a bit, this code untested and just to
give you an idea what I mean by posting a custom message, I hope it works :)
const
WM_CHECK_CONNECTED = WM_USER + 1;
protected
procedure WmCheckConnected(var Msg: TMessage); message WM_CHECK_CONNECTED;
{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *}
procedure TFtpReceiveForm.WmCheckConnected(var Msg: TMessage);
begin
if (FtpClient1.State in [ftpReady, ftpInternalReady, ftpPasvReady]) and
(not FtpClient1.Connected) then
//do what you like i.e.
FtpClient1.OpenAsync;
end;
{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *}
procedure TFtpReceiveForm.FtpClient1RequestDone(Sender: TObject;
RqType: TFtpRequest; Error: Word);
begin
Display('Request ' + IntToStr(Ord(RqType)) + ' Done.');
Display('StatusCode = ' + IntToStr(FtpClient1.StatusCode));
Display('LastResponse was : ''' + FtpClient1.LastResponse + );
if Error = 0 then
Display('No error')
else
Display('Error = ' + IntToStr(Error) +
' (' + FtpClient1.ErrorMessage + ')');
{ Display last progress value }
InfoLabel.Caption := IntToStr(FProgressCount);
if Error = 0 then begin
case RqType of
ftpDirAsync, ftpDirectoryAsync,
ftpLsAsync, ftpListAsync : DisplayFile(TEMP_FILE_NAME);
ftpSizeAsync: Display(
'File size is ' +
IntToStr(FtpClient1.SizeResult) +
' bytes' );
ftpPwdAsync, ftpMkdAsync,
ftpCDupAsync, ftpCwdAsync : Display(
'Directory is "' +
FtpClient1.DirResult + '"');
end;
end
// =>
else begin
{ Post a custom message if Get or Put failed. }
{ If the server has closed the control connection }
{ this message should be processed after OnSessionClosed triggered }
case RqType of
ftpGetAsync, ftpPutAsync : PostMessage(Handle, WM_CHECK_CONNECTED,
Ord(RqType), Error);
end;
end;
end;
{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *}
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
If I understand well what you say, in may case, when I cut off voluntarily the connection from server side, the datasocket must be closed and the Connected property must be True. Is that ? What I don't understand is : -if I launch a quitAsync => I've FTP Component not connected. And if I laucn connectAsync, I've "Ftp already connected" -or if I'm waiting 2 or 3 seconds after cut of the connection, Connected property set to false In fact, I'm sorry but I don't understand. So in the case where there is a problem on the line and there is a brutal disconnection, what can I test to know if I must launch a reconnection without waiting for 2 or 3 seconds ? Thanks a lot. Arnold FLUTEAUX wrote: > Indeed, Requestdone triggers but once time, the connected property is > set to true. > If I try to launch again a getasync command without reconnection, at > this time I have an error and the Connected property is set to False. > And side server, I launch FTPServer.disconnect property and the > client is disconnected. Nothing can be done at the same time ;-) So component behaviour is perfectly OK. 1) - Data connection is closed, RequestDone triggers, property Connected is still TRUE. 2) - Control connection is closed, OnSessionClosed triggers, property Connected is now FALSE. Note that in order to make number 2 happen messages need to be processed after number 1! But _never call ProcessMessages in RequestDone or any other event handler. Instead you could post a custom message from inside RequestDone and from the message handler check property Connected again and decide what to do next. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
Arnold FLUTEAUX wrote: > Indeed, Requestdone triggers but once time, the connected property is > set to true. > If I try to launch again a getasync command without reconnection, at > this time I have an error and the Connected property is set to False. > And side server, I launch FTPServer.disconnect property and the > client is disconnected. Nothing can be done at the same time ;-) So component behaviour is perfectly OK. 1) - Data connection is closed, RequestDone triggers, property Connected is still TRUE. 2) - Control connection is closed, OnSessionClosed triggers, property Connected is now FALSE. Note that in order to make number 2 happen messages need to be processed after number 1! But _never call ProcessMessages in RequestDone or any other event handler. Instead you could post a custom message from inside RequestDone and from the message handler check property Connected again and decide what to do next. > > What is curious is that in debug mode, if I make a pause, the > connected property set to false. > It's like if an event hadn't yet finished. > > > > Arnold FLUTEAUX wrote: >> Thanks for your response. >> I test it but when I cut on the connection with server during a >> download, a requestdone triggers but not the sessionclosed. > > Event OnSessionClosed is only triggered when the control connection > closes. When data connection closes only OnRequestDone fires. > So, in your case the server did not close the control connection, > you may probably start subsequent transfers without reconnect first. > > --- > Arno Garrels [TeamICS] -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
Indeed, Requestdone triggers but once time, the connected property is set to true. If I try to launch again a getasync command without reconnection, at this time I have an error and the Connected property is set to False. And side server, I launch FTPServer.disconnect property and the client is disconnected. What is curious is that in debug mode, if I make a pause, the connected property set to false. It's like if an event hadn't yet finished. Arnold FLUTEAUX wrote: > Thanks for your response. > I test it but when I cut on the connection with server during a > download, a requestdone triggers but not the sessionclosed. Event OnSessionClosed is only triggered when the control connection closes. When data connection closes only OnRequestDone fires. So, in your case the server did not close the control connection, you may probably start subsequent transfers without reconnect first. --- Arno Garrels [TeamICS] -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
Arnold FLUTEAUX wrote: > Thanks for your response. > I test it but when I cut on the connection with server during a > download, a requestdone triggers but not the sessionclosed. Event OnSessionClosed is only triggered when the control connection closes. When data connection closes only OnRequestDone fires. So, in your case the server did not close the control connection, you may probably start subsequent transfers without reconnect first. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
Thanks for your response.
I test it but when I cut on the connection with server during a download, a
requestdone triggers but not the sessionclosed.
Does it exist another trigger ?
Arnold FLUTEAUX wrote:
> Hello,
>
>
>
> Sorry but I've always my problem.
>
> I launch a GET and I kill the client connection on my FTP server.
> Then, I launch a new connection and I've an error which triggers in
> the OnError : FTP already connected. And in
> overbite.ICS.ftpclient.pas there is this test:
>
> if FConnected and (ftpFctOpen in Fcts) then begin
>
> HandleError('FTP component already connected');
>
> Exit;
>
> end;
>
>
Arnold,
you cannot reconnect until OnSessionClosed has been triggered.
>
> And the problem is that Fconnected is always to True while the
> connection is cut off.
If OnSessionClosed does not trigger the control connection is still
alive, means the server did only drop the data connection for some
reason.
When OnSessionClosed triggers post a custom window message and in
its message handler reconnect.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
>
> Please, what can I do ?
>
>
>
> Arnold
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
Arnold FLUTEAUX wrote:
> Hello,
>
>
>
> Sorry but I've always my problem.
>
> I launch a GET and I kill the client connection on my FTP server.
> Then, I launch a new connection and I've an error which triggers in
> the OnError : FTP already connected. And in
> overbite.ICS.ftpclient.pas there is this test:
>
> if FConnected and (ftpFctOpen in Fcts) then begin
>
> HandleError('FTP component already connected');
>
> Exit;
>
> end;
>
>
Arnold,
you cannot reconnect until OnSessionClosed has been triggered.
>
> And the problem is that Fconnected is always to True while the
> connection is cut off.
If OnSessionClosed does not trigger the control connection is still
alive, means the server did only drop the data connection for some
reason.
When OnSessionClosed triggers post a custom window message and in
its message handler reconnect.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
>
> Please, what can I do ?
>
>
>
> Arnold
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
To avoid this problem, I must make a 1 second pause and processmessages before launch a new connection. The "MakePause" procedure is like: FTPClient.ProcessMessages() intFinish = Timer + 1 Do While Timer < intTempsFinal Loop FTPClient.ProcessMessages() Is it natural to do it ? If I don't do that, onerror trigger return "FTP component already connected" because Fconnected is set to true. Arnold -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Problem with FTPClient when a shutdown
Hello,
Sorry but I've always my problem.
I launch a GET and I kill the client connection on my FTP server. Then, I
launch a new connection and I've an error which triggers in the OnError :
FTP already connected. And in overbite.ICS.ftpclient.pas there is this test:
if FConnected and (ftpFctOpen in Fcts) then begin
HandleError('FTP component already connected');
Exit;
end;
And the problem is that Fconnected is always to True while the connection is
cut off.
Please, what can I do ?
Arnold
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
