> what do you think?

The getter could be changed but this could break something elsewhere 
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,

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

Reply via email to