Re: [twsocket] Pop3 Compoent not ready
> I tried doing > try > Pop3Cli1.Quit > except > end; > > before calling the connect again however that didn't fix it Use Abort instead of Quit. -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: "Nick" <[EMAIL PROTECTED]> To: Sent: Wednesday, March 01, 2006 3:32 AM Subject: [twsocket] Pop3 Compoent not ready > Hi there, > > I am using Pop3Cli however, if I try and connect and say, my username or my > host is wrong, if I correct that and try again I get the error > > 'POP3 component not ready' > > if i close the software and open it again I can try and connect again with > out the above message > > I tried doing > try > Pop3Cli1.Quit > except > end; > > before calling the connect again however that didn't fix it > > Any idea? > -- > 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 -- 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] ICS documentation: a wiki has been setup
I've setup a wiki for ICS documentation. A few guys have helped to set it up: Arno, DZ, Guillaume, Wilfried, and some others. The system is working. We defined a layout and entered the component list, some component, the start of a FAQ and so on. Now we need writers to enter the actual data into the wiki. There is work for everybody: no need to know every details about ICS. If you can read source code, you can help a lot just by entering the properties, events and methods lists with a short description which is most of the time already in the source code. Other people with more knowledges can write extensive documentation about specific components they know better. Wiki is a collaboration tool. Everyone can give his 2 cents participation. Everybody willing to participate can explain (here in the list or by direct mail to me) what he can do. I will give write permission to the wiki. The wiki is available to everyone at http://wiki.overbyte.be There is a dedicated mailing list to discuss wiki content. Every writer will be invited of course. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be -- 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] About TWIrCommSocket
dear twsocket, I have got then TWIrCommSocket and Installed it on my computer.it's very good. but i have one question :how transmit one file(e.g. "d:\1.gif") to my mobile phone throught TWIrCommSocket? can you give me a example? I have stayed in this question a few days. thanks a lot. dengke chen [EMAIL PROTECTED] 2006-03-01 -- 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] About TWIrCommSocket
> how transmit one file(e.g. "d:\1.gif") > to my mobile phone throught TWIrCommSocket? I'm sorry, but TWIrCommSocket is not an ICS component. Therefore this mailing list is not the right place to ask for your question. I suggest you post to the general purpose Delphi mailing list (same server: http://www.elists.org/mailman/listinfo/delphi). -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be - Original Message - From: "陈登科" <[EMAIL PROTECTED]> To: Sent: Wednesday, March 01, 2006 9:44 AM Subject: [twsocket] About TWIrCommSocket dear twsocket, I have got then TWIrCommSocket and Installed it on my computer.it's very good. but i have one question :how transmit one file(e.g. "d:\1.gif") to my mobile phone throught TWIrCommSocket? can you give me a example? I have stayed in this question a few days. thanks a lot. dengke chen [EMAIL PROTECTED] 2006-03-01 > -- > 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 -- 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 v6 BCB package
What is your suggestion then? Regards, SubZ >> I don't like this idea. >> >> -- >> [EMAIL PROTECTED] >> http://www.overbyte.be >> >> - Original Message - >> From: "Fastream Technologies" <[EMAIL PROTECTED]> >> To: "ICS support mailing" >> Sent: Tuesday, February 28, 2006 7:58 AM >> Subject: Re: [twsocket] Problem with v6 BCB package >> >> >>> Francois, >>> >>> I think we should remove the library and types units and embed the >>> code into other units with direct Windows names. OR BETTER, we can >>> rename the functions as ICSGetWindowLong() and ICSHWND. I can do this >>> for you but I want to be assured that my changes will be applied and >>> therefore I would not have to do it every time a new version comes >>> out. >>> >>> Regards, >>> >>> SZ >>> >>> - Original Message - >>> From: "Dan" <[EMAIL PROTECTED]> >>> To: "ICS support mailing" >>> Sent: Monday, February 27, 2006 11:51 PM >>> Subject: Re: [twsocket] Problem with v6 BCB package >>> >>> >>> >I didn't think #defines followed namespaces, thought they were always >>> > global. Could be wrong... >>> > >>> > Dan >>> > >>> > - Original Message - >>> > From: "Fastream Technologies" <[EMAIL PROTECTED]> >>> > To: "ICS support mailing" >>> > Sent: Monday, February 27, 2006 2:19 PM >>> > Subject: Re: [twsocket] Problem with v6 BCB package >>> > >>> > >>> >> NO wait, you must have got the idea of how to make a namespace from >>> delphi: >>> >> it is easy and done in all ICS code as it is automatic in Delphi! >>> In Delphi >>> >> the unit name becomes the namespace name in C++! The problem is in >>> the current situation you -somehow- make the namespace contents >>> public and that >>> >> causes ambigouity with windows identifiers. We need to either: >>> >> >>> >> 1) make the namespace private and calls like >>> OverbyteIcs::getwindowlong >>> >> >>> >> OR >>> >> >>> >> 2) find a way to remove the namespace from within C++ source code. >>> For example: >>> >> >>> >> #include >>> >> #include >>> >> do NOT use namespace overbyteICS // not sure the syntax here! >>> #include >>> >> >>> >> Regards, >>> >> >>> >> SZ >>> >> >>> >> - Original Message - >>> >> From: "Francois Piette" <[EMAIL PROTECTED]> >>> >> To: "ICS support mailing" >>> >> Sent: Monday, February 27, 2006 4:00 PM >>> >> Subject: Re: [twsocket] Problem with v6 BCB package >>> >> >>> >> >>> >>>I have no idea about how to define C++ name space with Delphi code. >>> >>> -- >>> >>> [EMAIL PROTECTED] >>> >>> http://www.overbyte.be >>> >>> >>> >>> - Original Message - >>> >>> From: "Fastream Technologies" <[EMAIL PROTECTED]> >>> >>> To: "ICS support mailing" >>> >>> Sent: Monday, February 27, 2006 2:47 PM >>> >>> Subject: Re: [twsocket] Problem with v6 BCB package >>> >>> >>> >>> >>> No I don't think that would be easy as well... Why don't you use >>> namespaces >>> which are designed for this purpose? You should not include the >>> pascal translation of, >>> >>> use namespace overbyte; >>> >>> instead call functions like Overbyte::getwindowLong(); >>> >>> I understand that you wanted to simply the uses part of the >>> package but this >>> makes it further complicated in the projects. >>> >>> Regards, >>> >>> SZ >>> >>> - Original Message - >>> From: "Fastream Technologies" <[EMAIL PROTECTED]> >>> To: "ICS support mailing" >>> Sent: Monday, February 27, 2006 3:43 PM >>> Subject: Re: [twsocket] Problem with v6 BCB package >>> >>> >>> > This won't be as easy as to say: There are 20+ units! What >>> about including >>> > a >>> > special .h for this purpose that undefs all overbyte defs?? >>> > >>> > Regards, >>> > >>> > SZ >>> > >>> > - Original Message - >>> > From: "Francois Piette" <[EMAIL PROTECTED]> >>> > To: "ICS support mailing" >>> > Sent: Monday, February 27, 2006 3:23 PM >>> > Subject: Re: [twsocket] Problem with v6 BCB package >>> > >>> > >>> >> #ifdef HWND >>> >> #undef HWND >>> >> #endif >>> >> >>> >> Put this code (and similar) before the ICS includes. >>> >> Also try varying the include order between ICS and Windows. >>> >> >>> >> -- >>> >> [EMAIL PROTECTED] >>> >> http://www.overbyte.be >>> >> >>> >> - Original Message - >>> >> From: "Fastream Technologies" <[EMAIL PROTECTED]> >>> >> To: "ICS support mailing" >>> >> Sent: Monday, February 27, 2006 2:04 PM >>> >> Subject: Re: [twsocket] Problem with v6 BCB package >>> >> >>> >> >>> >>> Hello, >>> >>> >>> >>> - Original Message - >>> >>> From: "Francois Piette" <[EMAIL PROTECTED]> >>> >>> To: "ICS support mailing" >>> >>> Sent: Monday, February 27, 2006 12:56 PM >>> >>> Subject: Re: [twsocket] Problem with v6 BCB package >>> >>> >>> >>> >>> >>
Re: [twsocket] Problem with v6 BCB package
> What is your suggestion then? Continue to search how to turn on/off the definitions which are problematic with BCB6. -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: "Fastream Technologies" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Wednesday, March 01, 2006 10:40 AM Subject: Re: [twsocket] Problem with v6 BCB package > What is your suggestion then? > > Regards, > > SubZ > > >> I don't like this idea. > >> > >> -- > >> [EMAIL PROTECTED] > >> http://www.overbyte.be > >> > >> - Original Message - > >> From: "Fastream Technologies" <[EMAIL PROTECTED]> > >> To: "ICS support mailing" > >> Sent: Tuesday, February 28, 2006 7:58 AM > >> Subject: Re: [twsocket] Problem with v6 BCB package > >> > >> > >>> Francois, > >>> > >>> I think we should remove the library and types units and embed the > >>> code into other units with direct Windows names. OR BETTER, we can > >>> rename the functions as ICSGetWindowLong() and ICSHWND. I can do this > >>> for you but I want to be assured that my changes will be applied and > >>> therefore I would not have to do it every time a new version comes > >>> out. > >>> > >>> Regards, > >>> > >>> SZ > >>> > >>> - Original Message - > >>> From: "Dan" <[EMAIL PROTECTED]> > >>> To: "ICS support mailing" > >>> Sent: Monday, February 27, 2006 11:51 PM > >>> Subject: Re: [twsocket] Problem with v6 BCB package > >>> > >>> > >>> >I didn't think #defines followed namespaces, thought they were always > >>> > global. Could be wrong... > >>> > > >>> > Dan > >>> > > >>> > - Original Message - > >>> > From: "Fastream Technologies" <[EMAIL PROTECTED]> > >>> > To: "ICS support mailing" > >>> > Sent: Monday, February 27, 2006 2:19 PM > >>> > Subject: Re: [twsocket] Problem with v6 BCB package > >>> > > >>> > > >>> >> NO wait, you must have got the idea of how to make a namespace from > >>> delphi: > >>> >> it is easy and done in all ICS code as it is automatic in Delphi! > >>> In Delphi > >>> >> the unit name becomes the namespace name in C++! The problem is in > >>> the current situation you -somehow- make the namespace contents > >>> public and that > >>> >> causes ambigouity with windows identifiers. We need to either: > >>> >> > >>> >> 1) make the namespace private and calls like > >>> OverbyteIcs::getwindowlong > >>> >> > >>> >> OR > >>> >> > >>> >> 2) find a way to remove the namespace from within C++ source code. > >>> For example: > >>> >> > >>> >> #include > >>> >> #include > >>> >> do NOT use namespace overbyteICS // not sure the syntax here! > >>> #include > >>> >> > >>> >> Regards, > >>> >> > >>> >> SZ > >>> >> > >>> >> - Original Message - > >>> >> From: "Francois Piette" <[EMAIL PROTECTED]> > >>> >> To: "ICS support mailing" > >>> >> Sent: Monday, February 27, 2006 4:00 PM > >>> >> Subject: Re: [twsocket] Problem with v6 BCB package > >>> >> > >>> >> > >>> >>>I have no idea about how to define C++ name space with Delphi code. > >>> >>> -- > >>> >>> [EMAIL PROTECTED] > >>> >>> http://www.overbyte.be > >>> >>> > >>> >>> - Original Message - > >>> >>> From: "Fastream Technologies" <[EMAIL PROTECTED]> > >>> >>> To: "ICS support mailing" > >>> >>> Sent: Monday, February 27, 2006 2:47 PM > >>> >>> Subject: Re: [twsocket] Problem with v6 BCB package > >>> >>> > >>> >>> > >>> No I don't think that would be easy as well... Why don't you use > >>> namespaces > >>> which are designed for this purpose? You should not include the > >>> pascal translation of, > >>> > >>> use namespace overbyte; > >>> > >>> instead call functions like Overbyte::getwindowLong(); > >>> > >>> I understand that you wanted to simply the uses part of the > >>> package but this > >>> makes it further complicated in the projects. > >>> > >>> Regards, > >>> > >>> SZ > >>> > >>> - Original Message - > >>> From: "Fastream Technologies" <[EMAIL PROTECTED]> > >>> To: "ICS support mailing" > >>> Sent: Monday, February 27, 2006 3:43 PM > >>> Subject: Re: [twsocket] Problem with v6 BCB package > >>> > >>> > >>> > This won't be as easy as to say: There are 20+ units! What > >>> about including > >>> > a > >>> > special .h for this purpose that undefs all overbyte defs?? > >>> > > >>> > Regards, > >>> > > >>> > SZ > >>> > > >>> > - Original Message - > >>> > From: "Francois Piette" <[EMAIL PROTECTED]> > >>> > To: "ICS support mailing" > >>> > Sent: Monday, February 27, 2006 3:23 PM > >>> > Subject: Re: [twsocket] Problem with v6 BCB package > >>> > > >>> > > >>> >> #ifdef HWND > >>> >> #undef HWND > >>> >> #endif > >>> >> > >>> >> Put this code (and similar) before the ICS includes. > >>> >> Also try varying the include order between ICS and Windows. > >>> >> > >>> >> -- > >>> >> [EMAIL PROTECTE
Re: [twsocket] Problem with v6 BCB package
It is not just about my project! I create an empty project, drop a v6 httpserver component and it gives the same result! If you look at the vcl.components.using group of borland, you will see that the responses (including Remy from TeamB), there is no such way to "uninclude/exclude" a header in C++. I skimmed through the Stroustrup book and it's the same!! I think we need to rename the overriding functions with a prefix such as "Ics". Regards, SZ - Original Message - From: "Francois Piette" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Wednesday, March 01, 2006 12:05 PM Subject: Re: [twsocket] Problem with v6 BCB package >> What is your suggestion then? > > Continue to search how to turn on/off the definitions which are > problematic with BCB6. > -- > [EMAIL PROTECTED] > http://www.overbyte.be > > > - Original Message - > From: "Fastream Technologies" <[EMAIL PROTECTED]> > To: "ICS support mailing" > Sent: Wednesday, March 01, 2006 10:40 AM > Subject: Re: [twsocket] Problem with v6 BCB package > > >> What is your suggestion then? >> >> Regards, >> >> SubZ >> >> >> I don't like this idea. >> >> >> >> -- >> >> [EMAIL PROTECTED] >> >> http://www.overbyte.be >> >> >> >> - Original Message - >> >> From: "Fastream Technologies" <[EMAIL PROTECTED]> >> >> To: "ICS support mailing" >> >> Sent: Tuesday, February 28, 2006 7:58 AM >> >> Subject: Re: [twsocket] Problem with v6 BCB package >> >> >> >> >> >>> Francois, >> >>> >> >>> I think we should remove the library and types units and embed the >> >>> code into other units with direct Windows names. OR BETTER, we can >> >>> rename the functions as ICSGetWindowLong() and ICSHWND. I can do >> >>> this >> >>> for you but I want to be assured that my changes will be applied and >> >>> therefore I would not have to do it every time a new version comes >> >>> out. >> >>> >> >>> Regards, >> >>> >> >>> SZ >> >>> >> >>> - Original Message - >> >>> From: "Dan" <[EMAIL PROTECTED]> >> >>> To: "ICS support mailing" >> >>> Sent: Monday, February 27, 2006 11:51 PM >> >>> Subject: Re: [twsocket] Problem with v6 BCB package >> >>> >> >>> >> >>> >I didn't think #defines followed namespaces, thought they were >> >>> >always >> >>> > global. Could be wrong... >> >>> > >> >>> > Dan >> >>> > >> >>> > - Original Message - >> >>> > From: "Fastream Technologies" <[EMAIL PROTECTED]> >> >>> > To: "ICS support mailing" >> >>> > Sent: Monday, February 27, 2006 2:19 PM >> >>> > Subject: Re: [twsocket] Problem with v6 BCB package >> >>> > >> >>> > >> >>> >> NO wait, you must have got the idea of how to make a namespace >> >>> >> from >> >>> delphi: >> >>> >> it is easy and done in all ICS code as it is automatic in Delphi! >> >>> In Delphi >> >>> >> the unit name becomes the namespace name in C++! The problem is in >> >>> the current situation you -somehow- make the namespace contents >> >>> public and that >> >>> >> causes ambigouity with windows identifiers. We need to either: >> >>> >> >> >>> >> 1) make the namespace private and calls like >> >>> OverbyteIcs::getwindowlong >> >>> >> >> >>> >> OR >> >>> >> >> >>> >> 2) find a way to remove the namespace from within C++ source code. >> >>> For example: >> >>> >> >> >>> >> #include >> >>> >> #include >> >>> >> do NOT use namespace overbyteICS // not sure the syntax here! >> >>> #include >> >>> >> >> >>> >> Regards, >> >>> >> >> >>> >> SZ >> >>> >> >> >>> >> - Original Message - >> >>> >> From: "Francois Piette" <[EMAIL PROTECTED]> >> >>> >> To: "ICS support mailing" >> >>> >> Sent: Monday, February 27, 2006 4:00 PM >> >>> >> Subject: Re: [twsocket] Problem with v6 BCB package >> >>> >> >> >>> >> >> >>> >>>I have no idea about how to define C++ name space with Delphi >> >>> >>>code. >> >>> >>> -- >> >>> >>> [EMAIL PROTECTED] >> >>> >>> http://www.overbyte.be >> >>> >>> >> >>> >>> - Original Message - >> >>> >>> From: "Fastream Technologies" <[EMAIL PROTECTED]> >> >>> >>> To: "ICS support mailing" >> >>> >>> Sent: Monday, February 27, 2006 2:47 PM >> >>> >>> Subject: Re: [twsocket] Problem with v6 BCB package >> >>> >>> >> >>> >>> >> >>> No I don't think that would be easy as well... Why don't you use >> >>> namespaces >> >>> which are designed for this purpose? You should not include the >> >>> pascal translation of, >> >>> >> >>> use namespace overbyte; >> >>> >> >>> instead call functions like Overbyte::getwindowLong(); >> >>> >> >>> I understand that you wanted to simply the uses part of the >> >>> package but this >> >>> makes it further complicated in the projects. >> >>> >> >>> Regards, >> >>> >> >>> SZ >> >>> >> >>> - Original Message - >> >>> From: "Fastream Technologies" <[EMAIL PROTECTED]> >> >>> To: "ICS support mailing" >> >>> Sent: Monday, February 27, 2006 3:43 PM >> >>> Subject: Re: [twsocket] Problem with v6 BCB package >> >>> >> >
[twsocket] Triggering events when csDestroying is in ComponentState?
Hi, There are some events in WSocket.pas that may be triggered even though csDestroying is in the ComponentState. Shouldn't we check csDestroying before any event is fired? In a multithreading TWSocketServer app. it would help to avoid AV's. Arno -- 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] New property Pause in TWsocketServer
Hi, I would like to suggest a simple new boolean property Pause. If TRUE we would simply Exit from procedure TCustomWSocketServer.TriggerSessionAvailable. Also Pause should be set to TRUE in the destructor to avoid multithreading-troubles. What do you thing? Arno -- 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] New property Pause in TWsocketServer
Well, the name must be different. May be ListenPaused ?? Arno Garrels wrote: > Hi, > > I would like to suggest a simple new boolean property Pause. > If TRUE we would simply Exit from procedure > TCustomWSocketServer.TriggerSessionAvailable. > Also Pause should be set to TRUE in the destructor to avoid > multithreading-troubles. What do you thing? > > Arno -- 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] Triggering events when csDestroying is in ComponentState?
> There are some events in WSocket.pas that may be triggered > even though csDestroying is in the ComponentState. > Shouldn't we check csDestroying before any event is fired? > In a multithreading TWSocketServer app. it would help to > avoid AV's. It seems reasonable. But I wonder which event you have problem with. I've a lot of multithreaded applications and have not noticed this kind of problem. > I would like to suggest a simple new boolean property Pause. > If TRUE we would simply Exit from procedure > TCustomWSocketServer.TriggerSessionAvailable. There is already a method named Pause. Basically this is to make the component refuse to accept new connections. Why not simply close the socket ? > Also Pause should be set to TRUE in the destructor to avoid > multithreading-troubles. What do you thing? csDestroying is probably enough. -- [EMAIL PROTECTED] http://www.overbyte.be -- 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] Triggering events when csDestroying is inComponentState?
Francois Piette wrote: >> There are some events in WSocket.pas that may be triggered >> even though csDestroying is in the ComponentState. >> Shouldn't we check csDestroying before any event is fired? >> In a multithreading TWSocketServer app. it would help to >> avoid AV's. > > It seems reasonable. But I wonder which event you have problem with. I've > a lot of multithreaded applications and have not noticed this kind of > problem. When I destroy the SimpleThrdSslServer with alot of threads and clients I can avoid AV's by this code: function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean; begin Result := Assigned(FOnDataAvailable) and not (csDestroying in ComponentState); if not Result then Exit; ... > >> I would like to suggest a simple new boolean property Pause. >> If TRUE we would simply Exit from procedure >> TCustomWSocketServer.TriggerSessionAvailable. > > There is already a method named Pause. > Basically this is to make the component refuse to accept new connections. It pauses notification, I'm not 100% sure how Resume behaves, won't it sure fire no queued events? > Why not simply close the socket ? > >> Also Pause should be set to TRUE in the destructor to avoid >> multithreading-troubles. What do you thing? > > csDestroying is probably enough. > > -- > [EMAIL PROTECTED] > http://www.overbyte.be -- 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] Triggering events when csDestroying isinComponentState?
> When I destroy the SimpleThrdSslServer with alot of threads and clients > I can avoid AV's by this code: > > function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean; > begin > Result := Assigned(FOnDataAvailable) and not (csDestroying in > ComponentState); > if not Result then > Exit; > ... At first glance, I don't see why this code would cause trouble in existing application. But why don't put it in the application code ? > > Basically this is to make the component refuse to accept new connections. > > It pauses notification, I'm not 100% sure how Resume behaves, > won't it sure fire no queued events? Queued messages will still be processed, even after Pause has been called. Pause prevent winsock from posting more FD_XYZ messages. But already posted messages will be processed. -- [EMAIL PROTECTED] http://www.overbyte.be -- 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] Triggering events when csDestroyingisinComponentState?
Francois Piette wrote:
>> When I destroy the SimpleThrdSslServer with alot of threads and clients
>> I can avoid AV's by this code:
>>
>> function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
>> begin
>> Result := Assigned(FOnDataAvailable) and not (csDestroying in
>> ComponentState); if not Result then
>> Exit;
>> ...
>
> At first glance, I don't see why this code would cause trouble in
> existing application. But why don't put it in the application code ?
Because I think that DataAvailable should not be triggered when the
component is destroyed anyway, but I may be wrong.
I've played with the TWSocketThrdServer and modified it to always
wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
You know that the threads post WM_THREAD_TERMINATED at the end of
method execute to the server window. So, in destructor messages must
be processed. If you have a better idea please let me know.
May be this is the reason why I get random AV's in OnDataAvailable.
Note that I'm stress-testing with a client that connects, sends
a request and server echos the request, this all very fast, one
after the another, until there are up to thousand concurrent
connections.
procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
var
AThread : TWsClientThread;
I : Integer;
begin
AThread := TObject(Msg.WParam) as TWsClientThread;
I := FThreadList.IndexOf(AThread);
if I > -1 then
FThreadList.Delete(I);
AThread.WaitFor;
if Assigned(FOnBeforeThreadDestroy) then
FOnBeforeThreadDestroy(Self, AThread);
if not AThread.FreeOnTerminate then
AThread.Destroy;
end;
{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *}
procedure TWSocketThrdServer.TerminateThreads;
var
AThread : TWsClientThread;
I : Integer;
begin
for I := 0 to FThreadList.Count - 1 do begin
AThread := TWsClientThread(FThreadList[I]);
if PostThreadMessage(AThread.ThreadID,
WM_THREAD_TERMINATE, 0, 0) then begin
InterlockedDecrement(FThreadCount);
Sleep(0);
end;
end;
end;
destructor TWSocketThrdServer.Destroy;
var
WaitRes : LongWord;
Dummy : Byte;
Msg : tagMsg;
begin
Pause; // while waiting for our threads don't accept new clients!!
TerminateThreads;
try
if FThreadList.Count > 0 then
repeat
WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
QS_POSTMESSAGE or QS_SENDMESSAGE);
if WaitRes = WAIT_FAILED then
raise Exception.Create('Wait for threads failed ' +
SysErrorMessage(GetLastError))
else if WaitRes = WAIT_OBJECT_0 then
while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
begin
TranslateMessage(Msg);
DispatchMessage(Msg);
end;
until FThreadList.Count = 0;
finally
inherited Destroy;
FreeAndNil(FThreadList);
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] Triggering events when csDestroyingisinComponentState?
Hello Arno,
> Because I think that DataAvailable should not be triggered when the
> component is destroyed anyway, but I may be wrong.
As I recall it was by design that OnDataAvailable will trigger if there
is partial data in buffer. This can happen with LineMode set.
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Wednesday, March 1, 2006, 17:19, Arno Garrels wrote:
> Francois Piette wrote:
>>> When I destroy the SimpleThrdSslServer with alot of threads and clients
>>> I can avoid AV's by this code:
>>>
>>> function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
>>> begin
>>> Result := Assigned(FOnDataAvailable) and not (csDestroying in
>>> ComponentState); if not Result then
>>> Exit;
>>> ...
>>
>> At first glance, I don't see why this code would cause trouble in
>> existing application. But why don't put it in the application code ?
> Because I think that DataAvailable should not be triggered when the
> component is destroyed anyway, but I may be wrong.
> I've played with the TWSocketThrdServer and modified it to always
> wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
> You know that the threads post WM_THREAD_TERMINATED at the end of
> method execute to the server window. So, in destructor messages must
> be processed. If you have a better idea please let me know.
> May be this is the reason why I get random AV's in OnDataAvailable.
> Note that I'm stress-testing with a client that connects, sends
> a request and server echos the request, this all very fast, one
> after the another, until there are up to thousand concurrent
> connections.
> procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
> var
> AThread : TWsClientThread;
> I : Integer;
> begin
> AThread := TObject(Msg.WParam) as TWsClientThread;
> I := FThreadList.IndexOf(AThread);
> if I > -1 then
> FThreadList.Delete(I);
> AThread.WaitFor;
> if Assigned(FOnBeforeThreadDestroy) then
> FOnBeforeThreadDestroy(Self, AThread);
> if not AThread.FreeOnTerminate then
> AThread.Destroy;
> end;
> {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *}
> procedure TWSocketThrdServer.TerminateThreads;
> var
> AThread : TWsClientThread;
> I : Integer;
> begin
> for I := 0 to FThreadList.Count - 1 do begin
> AThread := TWsClientThread(FThreadList[I]);
> if PostThreadMessage(AThread.ThreadID,
> WM_THREAD_TERMINATE, 0, 0) then begin
> InterlockedDecrement(FThreadCount);
> Sleep(0);
> end;
> end;
> end;
> destructor TWSocketThrdServer.Destroy;
> var
> WaitRes : LongWord;
> Dummy : Byte;
> Msg : tagMsg;
> begin
> Pause; // while waiting for our threads don't accept new clients!!
> TerminateThreads;
> try
> if FThreadList.Count > 0 then
> repeat
> WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
> QS_POSTMESSAGE or
> QS_SENDMESSAGE);
> if WaitRes = WAIT_FAILED then
> raise Exception.Create('Wait for threads failed ' +
>SysErrorMessage(GetLastError))
> else if WaitRes = WAIT_OBJECT_0 then
> while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
> begin
> TranslateMessage(Msg);
> DispatchMessage(Msg);
> end;
> until FThreadList.Count = 0;
> finally
> inherited Destroy;
> FreeAndNil(FThreadList);
> 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] Triggering events whencsDestroyingisinComponentState?
Do you know what is causing the AV ?
I mean the AV occur from OndataAvailable but when accessing what ?
>From the destructor, the component is still allocated.
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Wednesday, March 01, 2006 5:19 PM
Subject: Re: [twsocket] Triggering events
whencsDestroyingisinComponentState?
> Francois Piette wrote:
>>> When I destroy the SimpleThrdSslServer with alot of threads and clients
>>> I can avoid AV's by this code:
>>>
>>> function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
>>> begin
>>> Result := Assigned(FOnDataAvailable) and not (csDestroying in
>>> ComponentState); if not Result then
>>> Exit;
>>> ...
>>
>> At first glance, I don't see why this code would cause trouble in
>> existing application. But why don't put it in the application code ?
>
> Because I think that DataAvailable should not be triggered when the
> component is destroyed anyway, but I may be wrong.
>
> I've played with the TWSocketThrdServer and modified it to always
> wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
> You know that the threads post WM_THREAD_TERMINATED at the end of
> method execute to the server window. So, in destructor messages must
> be processed. If you have a better idea please let me know.
> May be this is the reason why I get random AV's in OnDataAvailable.
> Note that I'm stress-testing with a client that connects, sends
> a request and server echos the request, this all very fast, one
> after the another, until there are up to thousand concurrent
> connections.
>
>
> procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
> var
>AThread : TWsClientThread;
>I : Integer;
> begin
>AThread := TObject(Msg.WParam) as TWsClientThread;
>I := FThreadList.IndexOf(AThread);
>if I > -1 then
>FThreadList.Delete(I);
>AThread.WaitFor;
>if Assigned(FOnBeforeThreadDestroy) then
>FOnBeforeThreadDestroy(Self, AThread);
>if not AThread.FreeOnTerminate then
>AThread.Destroy;
> end;
>
>
> {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> *}
> procedure TWSocketThrdServer.TerminateThreads;
> var
>AThread : TWsClientThread;
>I : Integer;
> begin
>for I := 0 to FThreadList.Count - 1 do begin
>AThread := TWsClientThread(FThreadList[I]);
>if PostThreadMessage(AThread.ThreadID,
> WM_THREAD_TERMINATE, 0, 0) then begin
>InterlockedDecrement(FThreadCount);
>Sleep(0);
>end;
>end;
> end;
>
>
> destructor TWSocketThrdServer.Destroy;
> var
>WaitRes : LongWord;
>Dummy : Byte;
>Msg : tagMsg;
> begin
>Pause; // while waiting for our threads don't accept new clients!!
>TerminateThreads;
>try
>if FThreadList.Count > 0 then
>repeat
>WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
> QS_POSTMESSAGE or
> QS_SENDMESSAGE);
>if WaitRes = WAIT_FAILED then
>raise Exception.Create('Wait for threads failed ' +
> SysErrorMessage(GetLastError))
>else if WaitRes = WAIT_OBJECT_0 then
>while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
>begin
>TranslateMessage(Msg);
>DispatchMessage(Msg);
>end;
>until FThreadList.Count = 0;
>finally
>inherited Destroy;
>FreeAndNil(FThreadList);
>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
--
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] HttpCli->GetASync() exception
Hi Francois,
> You should be able to catch it by assigning an event handler to
THttpCli.CtrlSocket.OnBgException
I followed your suggestion and created this :
=
HttpCli->CtrlSocket->OnBgException=HttpException;
HttpCli->GetASync();
=
void __fastcall HttpComponent::HttpException
(TObject *Sender, Exception *E, bool &CanClose)
{
DebugText("Exception occurred...");
}
=
Then I trigger an error situation by saving the received http data to a
TFileStream located on an USB memory stick which has insufficient free space
(as describer in my earlier mail). This will trigger an exception in
procedure TStream.WriteBuffer : 'Stream write error' which is located in
'...\Win32\rtl\common\classes.pas'.
Unfortunately, the exception does not cause the handler defined in
HttpCli->CtrlSocket->OnBgException to be called.
Do you have any ideas about what I'm doing wrong ?
Thank you,
Kris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Francois PIETTE
Sent: dinsdag 28 februari 2006 19:37
To: ICS support mailing
Subject: Re: [twsocket] HttpCli->GetASync() exception
> (1) How can I detect that procedure TStream.WriteBuffer has
> encountered a 'Stream write error' ? I need to catch this exception so
> I can abort the http transfer (HttpCli->Abort()), but haven't got a
> clue how/where to do this. Preferably I need a way to communicate this
> error so that
> HttpRequestDone() is able not only to take HttpCli->StatusCode into
> account, but also any stream write errors that might have occurred.
You should be able to catch it by assigning an event handler to
THttpCli.CtrlSocket.OnBgException.
Ideally I should expose this OnBgException in THttpCli.
> (2) I was wondering what the variable WORD Error in
> HttpRequestDone(TObject *Sender, THttpRequest RqType, WORD Error)
> actually means ?
Mostly winsock errors. Try accessing a host where no server is operating.
> (3) Is it correct to assume that, unlike the synchronous Get, the
> GetASync()-call does not need a Try{} since, as you already indicated,
> these exceptions are triggered in a different context anyway ?
Wrong. There may be exception in the early phase, before async operation
occurs.
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Kris Schoofs" <[EMAIL PROTECTED]>
To: "'ICS support mailing'"
Sent: Tuesday, February 28, 2006 7:15 PM
Subject: Re: [twsocket] HttpCli->GetASync() exception
> Francois,
>
> Thank you for your explanation.
>
> To get into more detail... I'm attempting to code something where I
> download
> a file using GetASync() and where I'm able to report *all* errors that
> might
> occur during the download process. However, I'm having some trouble
> handling
> some situations where things go wrong...
>
> Below is a very small piece of code that helps to illustrate the
> problem...
> =
> void HttpComponent::StartDownload(void)
> {
> HttpCli->OnDocBegin=HttpDocBegin;
> HttpCli->OnDocEnd=HttpDocEnd;
> HttpCli->OnRequestDone=HttpRequestDone;
> HttpCli1->GetASync();
> // *** No need for Try{} since exceptions are
> // *** triggered in a different context anyway ?
> }
> =
> void __fastcall HttpComponent::HttpRequestDone
> (TObject *Sender, THttpRequest RqType, WORD Error)
> {
> // *** Not sure what WORD Error actually contains ?
> DebugText("Error=%d",Error);
> DebugText("StatusCode=%d",HttpCli->StatusCode);
> }
> =
> void __fastcall HttpComponent::HttpDocBegin(TObject *Sender)
> {
> HttpCli->RcvdStream=new TFileStream(HttpDestinationFile,fmCreate);
> }
> =
> void __fastcall HttpComponent::HttpDocEnd(TObject *Sender)
> {
> delete HttpCli1->ReceivedStream;
> }
> =
> When everything goes well and HttpRequestDone() is eventually called I get
> :
> Error=0
> StatusCode=200 (=OK)
>
> I was wondering what would happen if the writing to the FileStream would
> fail for any reason (e.g. no more free space). To simulate such an error I
> saved the FileStream to an USB memory stick that did not have sufficient
> space on it to contain the downloaded file.
>
> This triggers following exception every time a piece of the downloaded
> file
> is written as soon as I run out of free space on the memory stick :
> => procedure TStream.WriteBuffer : 'Stream write error'
> When HttpRequestDone() is eventually called it will report :
> Error=0
> StatusCode=200 (=OK)
>
> Even though the actual http transfer never encountered a problem (as
> confirmed by StatusCode=200) things clearly went wrong when when writing
> the
> received data to the filestream.
>
> I have following questions which I hope someone can clarify :
>
> (1) How can I detect that procedure TStream.WriteBuffer has encountered a
> 'Stream write error' ? I need to catch this exception so I can abort the
> http transfer (HttpCli->Abort()), but haven't got a clue how/where to do
> this. Preferably I need a way to communicate this error so that
> HttpRequestDone() is able not only to tak
Re: [twsocket] Triggering events whencsDestroyingisinComponentState?
Francois PIETTE wrote:
> Do you know what is causing the AV ?
> I mean the AV occur from OndataAvailable but when accessing what ?
Hard to say. Here's an image: http://www.duodata.de/misc/thrdAV.png
The first line where the IDE shows the green arrow in procedure
TSimpleThreadedSslServerForm.ClientDataAvailable after the AV is
=> ProcessData(Sender as TMyClient);
Previous line is Display() but Display is wrapped in a critical section.
The AV happens when I destroy the component while the stressing client
is still trying to do his work.
>> From the destructor, the component is still allocated.
Yes
Arno
>
> --
> [EMAIL PROTECTED]
> http://www.overbyte.be
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Wednesday, March 01, 2006 5:19 PM
> Subject: Re: [twsocket] Triggering events
> whencsDestroyingisinComponentState?
>
>
>> Francois Piette wrote:
When I destroy the SimpleThrdSslServer with alot of threads and clients
I can avoid AV's by this code:
function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
begin
Result := Assigned(FOnDataAvailable) and not (csDestroying in
ComponentState); if not Result then
Exit;
...
>>>
>>> At first glance, I don't see why this code would cause trouble in
>>> existing application. But why don't put it in the application code ?
>>
>> Because I think that DataAvailable should not be triggered when the
>> component is destroyed anyway, but I may be wrong.
>>
>> I've played with the TWSocketThrdServer and modified it to always
>> wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
>> You know that the threads post WM_THREAD_TERMINATED at the end of
>> method execute to the server window. So, in destructor messages must
>> be processed. If you have a better idea please let me know.
>> May be this is the reason why I get random AV's in OnDataAvailable.
>> Note that I'm stress-testing with a client that connects, sends
>> a request and server echos the request, this all very fast, one
>> after the another, until there are up to thousand concurrent
>> connections.
>>
>>
>> procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
>> var
>>AThread : TWsClientThread;
>>I : Integer;
>> begin
>>AThread := TObject(Msg.WParam) as TWsClientThread;
>>I := FThreadList.IndexOf(AThread);
>>if I > -1 then
>>FThreadList.Delete(I);
>>AThread.WaitFor;
>>if Assigned(FOnBeforeThreadDestroy) then
>>FOnBeforeThreadDestroy(Self, AThread);
>>if not AThread.FreeOnTerminate then
>>AThread.Destroy;
>> end;
>>
>>
>> {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>> * *}
>> procedure TWSocketThrdServer.TerminateThreads;
>> var
>>AThread : TWsClientThread;
>>I : Integer;
>> begin
>>for I := 0 to FThreadList.Count - 1 do begin
>>AThread := TWsClientThread(FThreadList[I]);
>>if PostThreadMessage(AThread.ThreadID,
>> WM_THREAD_TERMINATE, 0, 0) then begin
>>InterlockedDecrement(FThreadCount);
>>Sleep(0);
>>end;
>>end;
>> end;
>>
>>
>> destructor TWSocketThrdServer.Destroy;
>> var
>>WaitRes : LongWord;
>>Dummy : Byte;
>>Msg : tagMsg;
>> begin
>>Pause; // while waiting for our threads don't accept new clients!!
>>TerminateThreads;
>>try
>>if FThreadList.Count > 0 then
>>repeat
>>WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
>> QS_POSTMESSAGE or
>> QS_SENDMESSAGE);
>>if WaitRes = WAIT_FAILED then
>>raise Exception.Create('Wait for threads failed ' +
>> SysErrorMessage(GetLastError))
>>else if WaitRes = WAIT_OBJECT_0 then
>>while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
>>begin
>>TranslateMessage(Msg);
>>DispatchMessage(Msg);
>>end;
>>until FThreadList.Count = 0;
>>finally
>>inherited Destroy;
>>FreeAndNil(FThreadList);
>>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
--
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] Triggering events whencsDestroyingisinComponentState?
Wilfried Mestdagh wrote:
> Hello Arno,
>
>> Because I think that DataAvailable should not be triggered when the
>> component is destroyed anyway, but I may be wrong.
>
> As I recall it was by design that OnDataAvailable will trigger if there
> is partial data in buffer. This can happen with LineMode set.
Yes, but if you are already in the destructor the question is, whether it
is still required to read remaining data from the buffer or not?
I think it isn't required.
Arno
>
> ---
> Rgds, Wilfried [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
> http://www.mestdagh.biz
>
> Wednesday, March 1, 2006, 17:19, Arno Garrels wrote:
>
>> Francois Piette wrote:
When I destroy the SimpleThrdSslServer with alot of threads and clients
I can avoid AV's by this code:
function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
begin
Result := Assigned(FOnDataAvailable) and not (csDestroying in
ComponentState); if not Result then
Exit;
...
>>>
>>> At first glance, I don't see why this code would cause trouble in
>>> existing application. But why don't put it in the application code ?
>
>> Because I think that DataAvailable should not be triggered when the
>> component is destroyed anyway, but I may be wrong.
>
>> I've played with the TWSocketThrdServer and modified it to always
>> wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
>> You know that the threads post WM_THREAD_TERMINATED at the end of
>> method execute to the server window. So, in destructor messages must
>> be processed. If you have a better idea please let me know.
>> May be this is the reason why I get random AV's in OnDataAvailable.
>> Note that I'm stress-testing with a client that connects, sends
>> a request and server echos the request, this all very fast, one
>> after the another, until there are up to thousand concurrent
>> connections.
>
>
>> procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
>> var
>> AThread : TWsClientThread;
>> I : Integer;
>> begin
>> AThread := TObject(Msg.WParam) as TWsClientThread;
>> I := FThreadList.IndexOf(AThread);
>> if I > -1 then
>> FThreadList.Delete(I);
>> AThread.WaitFor;
>> if Assigned(FOnBeforeThreadDestroy) then
>> FOnBeforeThreadDestroy(Self, AThread);
>> if not AThread.FreeOnTerminate then
>> AThread.Destroy;
>> end;
>
>
>> {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>> * *} procedure TWSocketThrdServer.TerminateThreads;
>> var
>> AThread : TWsClientThread;
>> I : Integer;
>> begin
>> for I := 0 to FThreadList.Count - 1 do begin
>> AThread := TWsClientThread(FThreadList[I]);
>> if PostThreadMessage(AThread.ThreadID,
>> WM_THREAD_TERMINATE, 0, 0) then begin
>> InterlockedDecrement(FThreadCount);
>> Sleep(0);
>> end;
>> end;
>> end;
>
>
>> destructor TWSocketThrdServer.Destroy;
>> var
>> WaitRes : LongWord;
>> Dummy : Byte;
>> Msg : tagMsg;
>> begin
>> Pause; // while waiting for our threads don't accept new clients!!
>> TerminateThreads;
>> try
>> if FThreadList.Count > 0 then
>> repeat
>> WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
>> QS_POSTMESSAGE or
>> QS_SENDMESSAGE); if WaitRes = WAIT_FAILED then
>> raise Exception.Create('Wait for threads failed ' +
>>SysErrorMessage(GetLastError))
>> else if WaitRes = WAIT_OBJECT_0 then
>> while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
>> begin
>> TranslateMessage(Msg);
>> DispatchMessage(Msg);
>> end;
>> until FThreadList.Count = 0;
>> finally
>> inherited Destroy;
>> FreeAndNil(FThreadList);
>> 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] Triggering events whencsDestroyingisinComponentState?
Is the AV occuring when the application is destroying ?
If yes, then maybe Display is the culprit, trying to display something on a
TMemo which is already destroyed.
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Wednesday, March 01, 2006 7:31 PM
Subject: Re: [twsocket] Triggering events
whencsDestroyingisinComponentState?
> Francois PIETTE wrote:
>> Do you know what is causing the AV ?
>> I mean the AV occur from OndataAvailable but when accessing what ?
>
> Hard to say. Here's an image: http://www.duodata.de/misc/thrdAV.png
>
> The first line where the IDE shows the green arrow in procedure
> TSimpleThreadedSslServerForm.ClientDataAvailable after the AV is
> => ProcessData(Sender as TMyClient);
> Previous line is Display() but Display is wrapped in a critical section.
> The AV happens when I destroy the component while the stressing client
> is still trying to do his work.
>
>>> From the destructor, the component is still allocated.
>
> Yes
>
> Arno
>
>>
>> --
>> [EMAIL PROTECTED]
>> http://www.overbyte.be
>>
>> - Original Message -
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Wednesday, March 01, 2006 5:19 PM
>> Subject: Re: [twsocket] Triggering events
>> whencsDestroyingisinComponentState?
>>
>>
>>> Francois Piette wrote:
> When I destroy the SimpleThrdSslServer with alot of threads and
> clients
> I can avoid AV's by this code:
>
> function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
> begin
> Result := Assigned(FOnDataAvailable) and not (csDestroying in
> ComponentState); if not Result then
> Exit;
> ...
At first glance, I don't see why this code would cause trouble in
existing application. But why don't put it in the application code ?
>>>
>>> Because I think that DataAvailable should not be triggered when the
>>> component is destroyed anyway, but I may be wrong.
>>>
>>> I've played with the TWSocketThrdServer and modified it to always
>>> wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
>>> You know that the threads post WM_THREAD_TERMINATED at the end of
>>> method execute to the server window. So, in destructor messages must
>>> be processed. If you have a better idea please let me know.
>>> May be this is the reason why I get random AV's in OnDataAvailable.
>>> Note that I'm stress-testing with a client that connects, sends
>>> a request and server echos the request, this all very fast, one
>>> after the another, until there are up to thousand concurrent
>>> connections.
>>>
>>>
>>> procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
>>> var
>>>AThread : TWsClientThread;
>>>I : Integer;
>>> begin
>>>AThread := TObject(Msg.WParam) as TWsClientThread;
>>>I := FThreadList.IndexOf(AThread);
>>>if I > -1 then
>>>FThreadList.Delete(I);
>>>AThread.WaitFor;
>>>if Assigned(FOnBeforeThreadDestroy) then
>>>FOnBeforeThreadDestroy(Self, AThread);
>>>if not AThread.FreeOnTerminate then
>>>AThread.Destroy;
>>> end;
>>>
>>>
>>> {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>> * *}
>>> procedure TWSocketThrdServer.TerminateThreads;
>>> var
>>>AThread : TWsClientThread;
>>>I : Integer;
>>> begin
>>>for I := 0 to FThreadList.Count - 1 do begin
>>>AThread := TWsClientThread(FThreadList[I]);
>>>if PostThreadMessage(AThread.ThreadID,
>>> WM_THREAD_TERMINATE, 0, 0) then begin
>>>InterlockedDecrement(FThreadCount);
>>>Sleep(0);
>>>end;
>>>end;
>>> end;
>>>
>>>
>>> destructor TWSocketThrdServer.Destroy;
>>> var
>>>WaitRes : LongWord;
>>>Dummy : Byte;
>>>Msg : tagMsg;
>>> begin
>>>Pause; // while waiting for our threads don't accept new clients!!
>>>TerminateThreads;
>>>try
>>>if FThreadList.Count > 0 then
>>>repeat
>>>WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
>>> QS_POSTMESSAGE or
>>> QS_SENDMESSAGE);
>>>if WaitRes = WAIT_FAILED then
>>>raise Exception.Create('Wait for threads failed ' +
>>> SysErrorMessage(GetLastError))
>>>else if WaitRes = WAIT_OBJECT_0 then
>>>while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
>>>begin
>>>TranslateMessage(Msg);
>>>DispatchMessage(Msg);
>>>end;
>>>until FThreadList.Count = 0;
>>>finally
>>>inherited Destroy;
>>>FreeAndNil(FThreadList);
>>>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 h
Re: [twsocket] Triggering events whencsDestroyingisinComponentState?
Hello Arno,
You are right. If you destroy a component you dont wants data from
it anuymore.
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Wednesday, March 1, 2006, 19:46, Arno Garrels wrote:
> Wilfried Mestdagh wrote:
>> Hello Arno,
>>
>>> Because I think that DataAvailable should not be triggered when the
>>> component is destroyed anyway, but I may be wrong.
>>
>> As I recall it was by design that OnDataAvailable will trigger if there
>> is partial data in buffer. This can happen with LineMode set.
> Yes, but if you are already in the destructor the question is, whether it
> is still required to read remaining data from the buffer or not?
> I think it isn't required.
> Arno
>>
>> ---
>> Rgds, Wilfried [TeamICS]
>> http://www.overbyte.be/eng/overbyte/teamics.html
>> http://www.mestdagh.biz
>>
>> Wednesday, March 1, 2006, 17:19, Arno Garrels wrote:
>>
>>> Francois Piette wrote:
> When I destroy the SimpleThrdSslServer with alot of threads and clients
> I can avoid AV's by this code:
>
> function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
> begin
> Result := Assigned(FOnDataAvailable) and not (csDestroying in
> ComponentState); if not Result then
> Exit;
> ...
At first glance, I don't see why this code would cause trouble in
existing application. But why don't put it in the application code ?
>>
>>> Because I think that DataAvailable should not be triggered when the
>>> component is destroyed anyway, but I may be wrong.
>>
>>> I've played with the TWSocketThrdServer and modified it to always
>>> wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
>>> You know that the threads post WM_THREAD_TERMINATED at the end of
>>> method execute to the server window. So, in destructor messages must
>>> be processed. If you have a better idea please let me know.
>>> May be this is the reason why I get random AV's in OnDataAvailable.
>>> Note that I'm stress-testing with a client that connects, sends
>>> a request and server echos the request, this all very fast, one
>>> after the another, until there are up to thousand concurrent
>>> connections.
>>
>>
>>> procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
>>> var
>>> AThread : TWsClientThread;
>>> I : Integer;
>>> begin
>>> AThread := TObject(Msg.WParam) as TWsClientThread;
>>> I := FThreadList.IndexOf(AThread);
>>> if I > -1 then
>>> FThreadList.Delete(I);
>>> AThread.WaitFor;
>>> if Assigned(FOnBeforeThreadDestroy) then
>>> FOnBeforeThreadDestroy(Self, AThread);
>>> if not AThread.FreeOnTerminate then
>>> AThread.Destroy;
>>> end;
>>
>>
>>> {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>> * *} procedure TWSocketThrdServer.TerminateThreads;
>>> var
>>> AThread : TWsClientThread;
>>> I : Integer;
>>> begin
>>> for I := 0 to FThreadList.Count - 1 do begin
>>> AThread := TWsClientThread(FThreadList[I]);
>>> if PostThreadMessage(AThread.ThreadID,
>>> WM_THREAD_TERMINATE, 0, 0) then begin
>>> InterlockedDecrement(FThreadCount);
>>> Sleep(0);
>>> end;
>>> end;
>>> end;
>>
>>
>>> destructor TWSocketThrdServer.Destroy;
>>> var
>>> WaitRes : LongWord;
>>> Dummy : Byte;
>>> Msg : tagMsg;
>>> begin
>>> Pause; // while waiting for our threads don't accept new clients!!
>>> TerminateThreads;
>>> try
>>> if FThreadList.Count > 0 then
>>> repeat
>>> WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
>>> QS_POSTMESSAGE or
>>> QS_SENDMESSAGE); if WaitRes = WAIT_FAILED then
>>> raise Exception.Create('Wait for threads failed ' +
>>>SysErrorMessage(GetLastError))
>>> else if WaitRes = WAIT_OBJECT_0 then
>>> while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
>>> begin
>>> TranslateMessage(Msg);
>>> DispatchMessage(Msg);
>>> end;
>>> until FThreadList.Count = 0;
>>> finally
>>> inherited Destroy;
>>> FreeAndNil(FThreadList);
>>> 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] Triggering events whencsDestroyingisinComponentState?
Hello Francois,
Yes for example I have a few applications where I use OnChangeState to
display this information. This need the if not Application.Terminated
check before displaying..
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Wednesday, March 1, 2006, 20:20, Francois PIETTE wrote:
> Is the AV occuring when the application is destroying ?
> If yes, then maybe Display is the culprit, trying to display something on a
> TMemo which is already destroyed.
> --
> [EMAIL PROTECTED]
> http://www.overbyte.be
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Wednesday, March 01, 2006 7:31 PM
> Subject: Re: [twsocket] Triggering events
> whencsDestroyingisinComponentState?
>> Francois PIETTE wrote:
>>> Do you know what is causing the AV ?
>>> I mean the AV occur from OndataAvailable but when accessing what ?
>>
>> Hard to say. Here's an image: http://www.duodata.de/misc/thrdAV.png
>>
>> The first line where the IDE shows the green arrow in procedure
>> TSimpleThreadedSslServerForm.ClientDataAvailable after the AV is
>> => ProcessData(Sender as TMyClient);
>> Previous line is Display() but Display is wrapped in a critical section.
>> The AV happens when I destroy the component while the stressing client
>> is still trying to do his work.
>>
From the destructor, the component is still allocated.
>>
>> Yes
>>
>> Arno
>>
>>>
>>> --
>>> [EMAIL PROTECTED]
>>> http://www.overbyte.be
>>>
>>> - Original Message -
>>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>>> To: "ICS support mailing"
>>> Sent: Wednesday, March 01, 2006 5:19 PM
>>> Subject: Re: [twsocket] Triggering events
>>> whencsDestroyingisinComponentState?
>>>
>>>
Francois Piette wrote:
>> When I destroy the SimpleThrdSslServer with alot of threads and
>> clients
>> I can avoid AV's by this code:
>>
>> function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
>> begin
>> Result := Assigned(FOnDataAvailable) and not (csDestroying in
>> ComponentState); if not Result then
>> Exit;
>> ...
>
> At first glance, I don't see why this code would cause trouble in
> existing application. But why don't put it in the application code ?
Because I think that DataAvailable should not be triggered when the
component is destroyed anyway, but I may be wrong.
I've played with the TWSocketThrdServer and modified it to always
wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
You know that the threads post WM_THREAD_TERMINATED at the end of
method execute to the server window. So, in destructor messages must
be processed. If you have a better idea please let me know.
May be this is the reason why I get random AV's in OnDataAvailable.
Note that I'm stress-testing with a client that connects, sends
a request and server echos the request, this all very fast, one
after the another, until there are up to thousand concurrent
connections.
procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
var
AThread : TWsClientThread;
I : Integer;
begin
AThread := TObject(Msg.WParam) as TWsClientThread;
I := FThreadList.IndexOf(AThread);
if I > -1 then
FThreadList.Delete(I);
AThread.WaitFor;
if Assigned(FOnBeforeThreadDestroy) then
FOnBeforeThreadDestroy(Self, AThread);
if not AThread.FreeOnTerminate then
AThread.Destroy;
end;
{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* *}
procedure TWSocketThrdServer.TerminateThreads;
var
AThread : TWsClientThread;
I : Integer;
begin
for I := 0 to FThreadList.Count - 1 do begin
AThread := TWsClientThread(FThreadList[I]);
if PostThreadMessage(AThread.ThreadID,
WM_THREAD_TERMINATE, 0, 0) then begin
InterlockedDecrement(FThreadCount);
Sleep(0);
end;
end;
end;
destructor TWSocketThrdServer.Destroy;
var
WaitRes : LongWord;
Dummy : Byte;
Msg : tagMsg;
begin
Pause; // while waiting for our threads don't accept new clients!!
TerminateThreads;
try
if FThreadList.Count > 0 then
repeat
WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
QS_POSTMESSAGE or
QS_SENDMESSAGE);
if WaitRes = WAIT_FAILED then
raise Exception.Create('Wait for threads failed ' +
SysErrorMessage(GetLastError))
else if WaitRes = WAIT_OBJECT_0 then
while PeekMess
[twsocket] POP3Cli not ready...?
Hi there, I am using Pop3Cli however, if I try and connect and say, my username or my host is wrong, if I correct that and try again I get the error 'POP3 component not ready' if i close the software and open it again I can try and connect again with out the above message I tried doing try Pop3Cli1.Quit except end; before calling the connect again however that didn't fix it Any idea? -- 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] Triggering events whencsDestroyingisinComponentState?
Francois PIETTE wrote:
> Is the AV occuring when the application is destroying ?
Yes, I'll give it a trial tomorrow. But generally, shouldn't we
disable triggers when the component is in status destroying?
That would avoid many possible troubles at the root?
Arno
> If yes, then maybe Display is the culprit, trying to display something on
> a TMemo which is already destroyed.
>
> --
> [EMAIL PROTECTED]
> http://www.overbyte.be
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Wednesday, March 01, 2006 7:31 PM
> Subject: Re: [twsocket] Triggering events
> whencsDestroyingisinComponentState?
>
>
>> Francois PIETTE wrote:
>>> Do you know what is causing the AV ?
>>> I mean the AV occur from OndataAvailable but when accessing what ?
>>
>> Hard to say. Here's an image: http://www.duodata.de/misc/thrdAV.png
>>
>> The first line where the IDE shows the green arrow in procedure
>> TSimpleThreadedSslServerForm.ClientDataAvailable after the AV is
>> => ProcessData(Sender as TMyClient);
>> Previous line is Display() but Display is wrapped in a critical section.
>> The AV happens when I destroy the component while the stressing client
>> is still trying to do his work.
>>
From the destructor, the component is still allocated.
>>
>> Yes
>>
>> Arno
>>
>>>
>>> --
>>> [EMAIL PROTECTED]
>>> http://www.overbyte.be
>>>
>>> - Original Message -
>>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>>> To: "ICS support mailing"
>>> Sent: Wednesday, March 01, 2006 5:19 PM
>>> Subject: Re: [twsocket] Triggering events
>>> whencsDestroyingisinComponentState?
>>>
>>>
Francois Piette wrote:
>> When I destroy the SimpleThrdSslServer with alot of threads and
>> clients
>> I can avoid AV's by this code:
>>
>> function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
>> begin
>> Result := Assigned(FOnDataAvailable) and not (csDestroying in
>> ComponentState); if not Result then
>> Exit;
>> ...
>
> At first glance, I don't see why this code would cause trouble in
> existing application. But why don't put it in the application code ?
Because I think that DataAvailable should not be triggered when the
component is destroyed anyway, but I may be wrong.
I've played with the TWSocketThrdServer and modified it to always
wait for the threads, now FreeOnTerminate is _always_ set to FALSE.
You know that the threads post WM_THREAD_TERMINATED at the end of
method execute to the server window. So, in destructor messages must
be processed. If you have a better idea please let me know.
May be this is the reason why I get random AV's in OnDataAvailable.
Note that I'm stress-testing with a client that connects, sends
a request and server echos the request, this all very fast, one
after the another, until there are up to thousand concurrent
connections.
procedure TWSocketThrdServer.WmThreadTerminated(var Msg: TMessage);
var
AThread : TWsClientThread;
I : Integer;
begin
AThread := TObject(Msg.WParam) as TWsClientThread;
I := FThreadList.IndexOf(AThread);
if I > -1 then
FThreadList.Delete(I);
AThread.WaitFor;
if Assigned(FOnBeforeThreadDestroy) then
FOnBeforeThreadDestroy(Self, AThread);
if not AThread.FreeOnTerminate then
AThread.Destroy;
end;
{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * *}
procedure TWSocketThrdServer.TerminateThreads;
var
AThread : TWsClientThread;
I : Integer;
begin
for I := 0 to FThreadList.Count - 1 do begin
AThread := TWsClientThread(FThreadList[I]);
if PostThreadMessage(AThread.ThreadID,
WM_THREAD_TERMINATE, 0, 0) then begin
InterlockedDecrement(FThreadCount);
Sleep(0);
end;
end;
end;
destructor TWSocketThrdServer.Destroy;
var
WaitRes : LongWord;
Dummy : Byte;
Msg : tagMsg;
begin
Pause; // while waiting for our threads don't accept new clients!!
TerminateThreads;
try
if FThreadList.Count > 0 then
repeat
WaitRes := MsgWaitForMultipleObjects(0, Dummy, FALSE, 500,
QS_POSTMESSAGE or
QS_SENDMESSAGE);
if WaitRes = WAIT_FAILED then
raise Exception.Create('Wait for threads failed ' +
SysErrorMessage(GetLastError))
else if WaitRes = WAIT_OBJECT_0 then
while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
begin
TranslateMessage(Msg);
Re: [twsocket] POP3Cli not ready...?
Nick wrote: > Hi there, > > I am using Pop3Cli however, if I try and connect and say, my username or > my host is wrong, if I correct that and try again I get the error > > 'POP3 component not ready' I'm not sure wether you unstood the async behaviour of ICS, if you are not sure have a look at: http://wiki.overbyte.be/wiki/index.php/Asynchronous_Paradigm > > if i close the software and open it again I can try and connect again > with out the above message > > I tried doing > try > Pop3Cli1.Quit > except > end; Method Pop3Cli1.Quit sends the command QUIT to the server, this doesn't not mean that the connection is already terminated, it depends on the POP3 server when the connection is closed. When SessionClosed is triggered the connection is in a status to safely reconnect. A quick and dirty workaround is to call Abort before reconnect. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > > before calling the connect again however that didn't fix it > > Any idea? -- 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] Triggering events whencsDestroyingisinComponentState?
>> Is the AV occuring when the application is destroying ? >> If yes, then maybe Display is the culprit, trying to display >> something on a TMemo which is already destroyed. > Yes, I'll give it a trial tomorrow. But generally, shouldn't we > disable triggers when the component is in status destroying? > That would avoid many possible troubles at the root? That's a matter of taste. And since it can be handled easily at the application level, I don't see any need to make it into the component. The risk is to break existing code. The risk is low but it exists. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be -- 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
