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
