>> The getter could be changed but this could break something elsewhere > > I don't know where else this might be impotant. Instead I thought that > V6 is an oportunity to get rid of the old ballast
Yes, indeed. This change would require to check everything again in details. I can affect any component. This is not as simple as simply remove the line from the code. -- [EMAIL PROTECTED] http://www.overbyte.be ----- Original Message ----- From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" <twsocket@elists.org> Sent: Friday, June 23, 2006 9:47 PM Subject: Re: [twsocket] V6 ThreadDetach #2 > Francois PIETTE wrote: >>> what do you think? >> >> The getter could be changed but this could break something elsewhere > > I don't know where else this might be impotant. Instead I thought that > V6 is an oportunity to get rid of the old ballast > >> depending on the handle being created when needed. Since checking the >> handle value is useful to know if attached or not to a thread, maybe >> a simple new method IsThreadAttached could be created, just returning >> Result := FHandle <> 0; >> Then the offending code could be changed to: >> if Assigned(FServer) and FServer.IsThreadAttached then >> PostMessage(Server.Handle, Server.FMsg_WM_CLIENT_CLOSED, > > That won't help, because that client would never be freed. If the > developer detaches the window handle he becomes responsible for what > was doing, so raising a meaningfull error rather than allocating a new > window in the background is the wayto go, mytwo cents. > > >> >> btw: IsThreadAttached is probably the best name. It's just was is >> passing thru my head now. >> >> -- >> Contribute to the SSL Effort. Visit >> http://www.overbyte.be/eng/ssl.html -- >> [EMAIL PROTECTED] >> http://www.overbyte.be >> >> >> >> ----- Original Message ----- >> From: "Arno Garrels" <[EMAIL PROTECTED]> >> To: "ICS support mailing" <twsocket@elists.org> >> Sent: Friday, June 23, 2006 9:12 PM >> Subject: Re: [twsocket] V6 ThreadDetach #2 >> >> >>> Francois PIETTE wrote: >>>> You get the session closed after calling ThreadDetach ? >>> >>> Yes, since I'm always stress testing. A client may disconnect at >>> any time. It would be more straight ahead if the getter would become >>> a real getter (returning zero if there's no window available) then >>> checking the return value of PostMessage and raising an exception if >>> necessary, in this case it propably would be something like >>> "Invalid handle" that would make much more sense finding the bug, >>> what do you think? >>> >>> >>> --- >>> Arno Garrels [TeamICS] >>> http://www.overbyte.be/eng/overbyte/teamics.html >>> >>> >>> >>>> -- >>>> [EMAIL PROTECTED] >>>> http://www.overbyte.be >>>> >>>> ----- Original Message ----- >>>> From: "Arno Garrels" <[EMAIL PROTECTED]> >>>> To: "ICS support mailing" <twsocket@elists.org> >>>> Sent: Friday, June 23, 2006 8:55 AM >>>> Subject: Re: [twsocket] V6 ThreadDetach #2 >>>> >>>> >>>>> Already got it! It is as I wrote in my previous mail... >>>>> >>>>> procedure TWSocketClient.TriggerSessionClosed(ErrCode : Word); >>>>> begin >>>>> if not FSessionClosedFlag then begin >>>>> FSessionClosedFlag := TRUE; >>>>> if Assigned(FServer) then >>>>> PostMessage(Server.Handle, Server.FMsg_WM_CLIENT_CLOSED, >>>>> ErrCode, >>>>> {$IFDEF CLR} >>>>> Integer(IntPtr(Self.HandleGc))); >>>>> {$ENDIF} >>>>> {$IFDEF WIN32} >>>>> LongInt(Self)); >>>>> {$ENDIF} >>>>> inherited TriggerSessionClosed(ErrCode); >>>>> end; >>>>> end; >>>>> >>>>> A getter that automatically allocates a new window handle is a bad >>>>> solution! >>>>> >>>>> >>>>> >>>>> Francois Piette wrote: >>>>>> For debugging purpose, do this: >>>>>> >>>>>> Create a global public variable in wndcontrol, initialize it to >>>>>> false. >>>>>>> From your thread exceute, just after threaddetach, set it to >>>>>>> true. From the routine where the window handle is allocated (I >>>>>>> haven't the code >>>>>> here, I do from my head), add this: >>>>>> if MyGlobalVar then >>>>>> OutputDebugString('Got it'); >>>>>> Then place a breakpoint on the OutputDebugString line and run your >>>>>> program. When (if) the breakpoint is hit, have a look at the stack >>>>>> trace to understand where it comes from. >>>>>> >>>>>> 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: "Arno Garrels" <[EMAIL PROTECTED]> >>>>>> To: "ICS support mailing" <twsocket@elists.org> >>>>>> Sent: Thursday, June 22, 2006 9:37 PM >>>>>> Subject: Re: [twsocket] V6 ThreadDetach #2 >>>>>> >>>>>> >>>>>>> Arno Garrels wrote: >>>>>>>> Francois PIETTE wrote: >>>>>>>>>> Not sure what you mean. The problem is that even if you call >>>>>>>>>> ThreadDetach (which is to make the component windowless) you >>>>>>>>>> cannot be sure that the component will not allocate another >>>>>>>>>> window handle somewhere in the background >>>>>>>>>> after that call to ThreadDetach. >>>>>>>>> >>>>>>>>> I don't see how the component would create another window >>>>>>>>> handle once ThreadDetach has been called: no event will be >>>>>>>>> generated anymore. Only the currently executing event will >>>>>>>>> continue execution ans far as memory serve me well, no event >>>>>>>>> recreate a window handle. >>>>>>> >>>>>>> Typo, sorry! >>>>>>> >>>>>>> Correction: >>>>>>> >>>>>>> If so, why do I get this exception? ThreadDetach is executed and >>>>>>> property Handle is set to zero. Nevertheless the exeption is >>>>>>> raised. So a window handle must have been allocated after the >>>>>>> call to ThreadDetach somewhere. Please tell me what might be >>>>>>> wrong with the very simple code I posted before. There's no >>>>>>> deadlock, sure. Especially not if you exchange WaitFor by >>>>>>> WaitForSingleObject. Also, as far as I can see entire methode >>>>>>> ThreadDetach is blocking, so the thread shouldn't signal before >>>>>>> the window handle was set to zero, right? -- >>>>>>> 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 >>> -- >>> 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 -- 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
