You get the session closed after calling ThreadDetach ?
--
[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
