Re: [twsocket] Possible bug and solution in TWndControl
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Arno Garrels
> Sent: 07 February 2007 17:08
> To: ICS support mailing
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
> Fastream Technologies wrote:
> >> Initialize means you assign it in an Intialization section, do you?
> >
> > There is no such technique in C++! I have an intermediate Pascal
> > class but I did not notice this technique.
>
> I was hoping you teached me how to do the same in C++, anyway make
> sure this variable is set before any ICS V6 object is created. Most
> secure however is an initialization section. Changing it later,
> after the first number has been allocated with default value will
> probably cause errors.
>
I think the only way is to use a static variable. Something like this (may
contain syntax errors but you get the idea):
bool initSomething()
{
// your initialisation code here
return true;
}
static bool dummyBool = initSomething();
Dan
--
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] Possible bug and solution in TWndControl
Fastream Technologies wrote: >> Initialize means you assign it in an Intialization section, do you? > > There is no such technique in C++! I have an intermediate Pascal > class but I did not notice this technique. I was hoping you teached me how to do the same in C++, anyway make sure this variable is set before any ICS V6 object is created. Most secure however is an initialization section. Changing it later, after the first number has been allocated with default value will probably cause errors. > >> What is the purpose of creating a plain WndHandler in a worker >> thread? Please explain. > > To have a never destructed handler until the thread is destructed > itself! For SPEED! > > Best Regards, > > SZ -- 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] Possible bug and solution in TWndControl
BTW, you may have wondered why don't you debug the TIcsWndHandler from
within your project? The problem is my application immediately goes out of
memory when compiled in debug mode! With some tweaks I can put breakpoints
to C++ parts but does not let me in Pascal!!!
Please DO HELP!
Regards,
SZ
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Wednesday, February 07, 2007 3:11 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Fastream Technologies wrote:
>> Arno,
>>
>> - Original Message -
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Wednesday, February 07, 2007 2:43 PM
>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>
>>
>>> Fastream Technologies wrote:
>>>
>>>> I did not understand what you propose to have a single wndhandler
>>>> per thread with messages starting from WM_APP + 100--how to do it
>>>> properly?
>>>
>>> As we discussed yesterday, increase value of constant WH_MAX_MSG,
>>> the higher the value the less windows will be created but performance
>>> may decrease. An option to _force_ only one single window is not
>>> available in the component. Initialize global variable
>>> GWndHandlerMsgLow to change the base of allocated message numbers.
>>
>> I believe you are not getting all of my messages (I cannot exactly
>> see them since I am using Gmail and Gmail blocks the messages I send
>> to mailing lists). Anyway, the WM_USER + 1 is hard coded:
>
> Initialize means you assign it in an Intialization section, do you?
> What is the purpose of creating a plain WndHandler in a worker thread?
> Please explain.
>
>
>>
>> I traced the bug to here:
>>
>> function TIcsWndHandlerPool.GetWndHandler(
>> HandlerCount : UINT;
>> ThreadID : THandle) : TIcsWndHandler;
>> var
>> I : Integer;
>> L : TIcsWndHandlerList;
>> begin
>> // Search the list which has same thread ID
>> I := FList.Count - 1;
>> while (I >= 0) and
>> (TIcsWndHandlerList(FList.Items[I]).ThreadID <> ThreadID) do
>> Dec(I);
>> if I >= 0 then
>> L := TIcsWndHandlerList(FList.Items[I])
>> else begin
>> // No list found. Create a new one
>> L := TIcsWndHandlerList.Create;
>> L.ThreadID := ThreadID;
>> FList.Add(L);
>> end;
>>
>> // Search the list for a WndHandler with enough MsgHandlers
>> available I := 0;
>> while I < L.Count do begin
>> Result := TIcsWndHandler(L.Items[I]);
>> if Result.GetMsgLeft >= HandlerCount then
>> Exit;
>> Inc(I);
>> end;
>> Result:= TIcsWndHandler.Create;
>> Result.FOwnerList := L;
>> OutputDebugString(PChar('TIcsWndHandler.Create OwnerList = ' +
>> IntToHex(Integer(Result.FOwnerList), 8)));
>> Result.MsgLow := WM_USER + 1; // The EIP comes here, does not
>> use my wndhandler in thread!
>> L.Add(Result);
>> end;
>>
>> This occurs in threadattach in the thread code I sent!
>>
>> Best Regards,
>>
>> SZ
>>
>>
>>>
>>> Why do you want to debug and tune all at the same time? Usually
>>> I start tweaking (known) parameters once the app. runs stable
>>> with default settings.
>>>
>>> ---
>>> Arno Garrels [TeamICS]
>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>
>>>
>>>>>
>>>>> And check for HWND = 0 if you process custom thread messages sent
>>>>> by PostThreadMessage() (just to be sure).
>>>>
>>>> Already doing this.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> SZ
>>>>>>
>>>>>> - Original Message -
>>>>>> From: "Wilfried Mestdagh" <[EMAIL PROTECTED]>
>>>>>> To: "ICS support mailing"
>>>>>> Sent: Tuesday, February 06, 2007 10:17 PM
>>>>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>> It is just a simple constant, why shouldn&#
Re: [twsocket] Possible bug and solution in TWndControl
Arno, can you tell me what to put in a THttpConnection descendent? Also in
the same thread, there is also THttpCli's existing. But they are directly
inherited from the ICS code to C++ which has no "initialization" technique!
What would you suggest?
Thanks!
SZ
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Wednesday, February 07, 2007 3:11 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Fastream Technologies wrote:
>> Arno,
>>
>> - Original Message -
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Wednesday, February 07, 2007 2:43 PM
>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>
>>
>>> Fastream Technologies wrote:
>>>
>>>> I did not understand what you propose to have a single wndhandler
>>>> per thread with messages starting from WM_APP + 100--how to do it
>>>> properly?
>>>
>>> As we discussed yesterday, increase value of constant WH_MAX_MSG,
>>> the higher the value the less windows will be created but performance
>>> may decrease. An option to _force_ only one single window is not
>>> available in the component. Initialize global variable
>>> GWndHandlerMsgLow to change the base of allocated message numbers.
>>
>> I believe you are not getting all of my messages (I cannot exactly
>> see them since I am using Gmail and Gmail blocks the messages I send
>> to mailing lists). Anyway, the WM_USER + 1 is hard coded:
>
> Initialize means you assign it in an Intialization section, do you?
> What is the purpose of creating a plain WndHandler in a worker thread?
> Please explain.
>
>
>>
>> I traced the bug to here:
>>
>> function TIcsWndHandlerPool.GetWndHandler(
>> HandlerCount : UINT;
>> ThreadID : THandle) : TIcsWndHandler;
>> var
>> I : Integer;
>> L : TIcsWndHandlerList;
>> begin
>> // Search the list which has same thread ID
>> I := FList.Count - 1;
>> while (I >= 0) and
>> (TIcsWndHandlerList(FList.Items[I]).ThreadID <> ThreadID) do
>> Dec(I);
>> if I >= 0 then
>> L := TIcsWndHandlerList(FList.Items[I])
>> else begin
>> // No list found. Create a new one
>> L := TIcsWndHandlerList.Create;
>> L.ThreadID := ThreadID;
>> FList.Add(L);
>> end;
>>
>> // Search the list for a WndHandler with enough MsgHandlers
>> available I := 0;
>> while I < L.Count do begin
>> Result := TIcsWndHandler(L.Items[I]);
>> if Result.GetMsgLeft >= HandlerCount then
>> Exit;
>> Inc(I);
>> end;
>> Result:= TIcsWndHandler.Create;
>> Result.FOwnerList := L;
>> OutputDebugString(PChar('TIcsWndHandler.Create OwnerList = ' +
>> IntToHex(Integer(Result.FOwnerList), 8)));
>> Result.MsgLow := WM_USER + 1; // The EIP comes here, does not
>> use my wndhandler in thread!
>> L.Add(Result);
>> end;
>>
>> This occurs in threadattach in the thread code I sent!
>>
>> Best Regards,
>>
>> SZ
>>
>>
>>>
>>> Why do you want to debug and tune all at the same time? Usually
>>> I start tweaking (known) parameters once the app. runs stable
>>> with default settings.
>>>
>>> ---
>>> Arno Garrels [TeamICS]
>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>
>>>
>>>>>
>>>>> And check for HWND = 0 if you process custom thread messages sent
>>>>> by PostThreadMessage() (just to be sure).
>>>>
>>>> Already doing this.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> SZ
>>>>>>
>>>>>> - Original Message -
>>>>>> From: "Wilfried Mestdagh" <[EMAIL PROTECTED]>
>>>>>> To: "ICS support mailing"
>>>>>> Sent: Tuesday, February 06, 2007 10:17 PM
>>>>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>> It is just a simple constant, why shouldn't it be 800 instead of
Re: [twsocket] Possible bug and solution in TWndControl
FYI, it is still not working with the WMAPP+100 fix I posted. I still get
test exceptions. Francois I sent you a private email, have you received it?
Best Regards,
SZ
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Wednesday, February 07, 2007 3:11 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Fastream Technologies wrote:
>> Arno,
>>
>> - Original Message -
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Wednesday, February 07, 2007 2:43 PM
>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>
>>
>>> Fastream Technologies wrote:
>>>
>>>> I did not understand what you propose to have a single wndhandler
>>>> per thread with messages starting from WM_APP + 100--how to do it
>>>> properly?
>>>
>>> As we discussed yesterday, increase value of constant WH_MAX_MSG,
>>> the higher the value the less windows will be created but performance
>>> may decrease. An option to _force_ only one single window is not
>>> available in the component. Initialize global variable
>>> GWndHandlerMsgLow to change the base of allocated message numbers.
>>
>> I believe you are not getting all of my messages (I cannot exactly
>> see them since I am using Gmail and Gmail blocks the messages I send
>> to mailing lists). Anyway, the WM_USER + 1 is hard coded:
>
> Initialize means you assign it in an Intialization section, do you?
> What is the purpose of creating a plain WndHandler in a worker thread?
> Please explain.
>
>
>>
>> I traced the bug to here:
>>
>> function TIcsWndHandlerPool.GetWndHandler(
>> HandlerCount : UINT;
>> ThreadID : THandle) : TIcsWndHandler;
>> var
>> I : Integer;
>> L : TIcsWndHandlerList;
>> begin
>> // Search the list which has same thread ID
>> I := FList.Count - 1;
>> while (I >= 0) and
>> (TIcsWndHandlerList(FList.Items[I]).ThreadID <> ThreadID) do
>> Dec(I);
>> if I >= 0 then
>> L := TIcsWndHandlerList(FList.Items[I])
>> else begin
>> // No list found. Create a new one
>> L := TIcsWndHandlerList.Create;
>> L.ThreadID := ThreadID;
>> FList.Add(L);
>> end;
>>
>> // Search the list for a WndHandler with enough MsgHandlers
>> available I := 0;
>> while I < L.Count do begin
>> Result := TIcsWndHandler(L.Items[I]);
>> if Result.GetMsgLeft >= HandlerCount then
>> Exit;
>> Inc(I);
>> end;
>> Result:= TIcsWndHandler.Create;
>> Result.FOwnerList := L;
>> OutputDebugString(PChar('TIcsWndHandler.Create OwnerList = ' +
>> IntToHex(Integer(Result.FOwnerList), 8)));
>> Result.MsgLow := WM_USER + 1; // The EIP comes here, does not
>> use my wndhandler in thread!
>> L.Add(Result);
>> end;
>>
>> This occurs in threadattach in the thread code I sent!
>>
>> Best Regards,
>>
>> SZ
>>
>>
>>>
>>> Why do you want to debug and tune all at the same time? Usually
>>> I start tweaking (known) parameters once the app. runs stable
>>> with default settings.
>>>
>>> ---
>>> Arno Garrels [TeamICS]
>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>
>>>
>>>>>
>>>>> And check for HWND = 0 if you process custom thread messages sent
>>>>> by PostThreadMessage() (just to be sure).
>>>>
>>>> Already doing this.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> SZ
>>>>>>
>>>>>> - Original Message -
>>>>>> From: "Wilfried Mestdagh" <[EMAIL PROTECTED]>
>>>>>> To: "ICS support mailing"
>>>>>> Sent: Tuesday, February 06, 2007 10:17 PM
>>>>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>> It is just a simple constant, why shouldn't it be 800 instead of
>>>>>>>> 100??
>>>>>>>
>>>>>>> Because it is not t
Re: [twsocket] Possible bug and solution in TWndControl
Hello, - Original Message - From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Wednesday, February 07, 2007 3:11 PM Subject: Re: [twsocket] Possible bug and solution in TWndControl > Fastream Technologies wrote: >> Arno, >> >> - Original Message - >> From: "Arno Garrels" <[EMAIL PROTECTED]> >> To: "ICS support mailing" >> Sent: Wednesday, February 07, 2007 2:43 PM >> Subject: Re: [twsocket] Possible bug and solution in TWndControl >> >> >>> Fastream Technologies wrote: >>> >>>> I did not understand what you propose to have a single wndhandler >>>> per thread with messages starting from WM_APP + 100--how to do it >>>> properly? >>> >>> As we discussed yesterday, increase value of constant WH_MAX_MSG, >>> the higher the value the less windows will be created but performance >>> may decrease. An option to _force_ only one single window is not >>> available in the component. Initialize global variable >>> GWndHandlerMsgLow to change the base of allocated message numbers. >> >> I believe you are not getting all of my messages (I cannot exactly >> see them since I am using Gmail and Gmail blocks the messages I send >> to mailing lists). Anyway, the WM_USER + 1 is hard coded: > > Initialize means you assign it in an Intialization section, do you? There is no such technique in C++! I have an intermediate Pascal class but I did not notice this technique. > What is the purpose of creating a plain WndHandler in a worker thread? > Please explain. To have a never destructed handler until the thread is destructed itself! For SPEED! Best Regards, SZ -- 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] Possible bug and solution in TWndControl
Fastream Technologies wrote:
> Arno,
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Wednesday, February 07, 2007 2:43 PM
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
>
>> Fastream Technologies wrote:
>>
>>> I did not understand what you propose to have a single wndhandler
>>> per thread with messages starting from WM_APP + 100--how to do it
>>> properly?
>>
>> As we discussed yesterday, increase value of constant WH_MAX_MSG,
>> the higher the value the less windows will be created but performance
>> may decrease. An option to _force_ only one single window is not
>> available in the component. Initialize global variable
>> GWndHandlerMsgLow to change the base of allocated message numbers.
>
> I believe you are not getting all of my messages (I cannot exactly
> see them since I am using Gmail and Gmail blocks the messages I send
> to mailing lists). Anyway, the WM_USER + 1 is hard coded:
Initialize means you assign it in an Intialization section, do you?
What is the purpose of creating a plain WndHandler in a worker thread?
Please explain.
>
> I traced the bug to here:
>
> function TIcsWndHandlerPool.GetWndHandler(
> HandlerCount : UINT;
> ThreadID : THandle) : TIcsWndHandler;
> var
> I : Integer;
> L : TIcsWndHandlerList;
> begin
> // Search the list which has same thread ID
> I := FList.Count - 1;
> while (I >= 0) and
> (TIcsWndHandlerList(FList.Items[I]).ThreadID <> ThreadID) do
> Dec(I);
> if I >= 0 then
> L := TIcsWndHandlerList(FList.Items[I])
> else begin
> // No list found. Create a new one
> L := TIcsWndHandlerList.Create;
> L.ThreadID := ThreadID;
> FList.Add(L);
> end;
>
> // Search the list for a WndHandler with enough MsgHandlers
> available I := 0;
> while I < L.Count do begin
> Result := TIcsWndHandler(L.Items[I]);
> if Result.GetMsgLeft >= HandlerCount then
> Exit;
> Inc(I);
> end;
> Result:= TIcsWndHandler.Create;
> Result.FOwnerList := L;
> OutputDebugString(PChar('TIcsWndHandler.Create OwnerList = ' +
> IntToHex(Integer(Result.FOwnerList), 8)));
> Result.MsgLow := WM_USER + 1; // The EIP comes here, does not
> use my wndhandler in thread!
> L.Add(Result);
> end;
>
> This occurs in threadattach in the thread code I sent!
>
> Best Regards,
>
> SZ
>
>
>>
>> Why do you want to debug and tune all at the same time? Usually
>> I start tweaking (known) parameters once the app. runs stable
>> with default settings.
>>
>> ---
>> Arno Garrels [TeamICS]
>> http://www.overbyte.be/eng/overbyte/teamics.html
>>
>>
>>>>
>>>> And check for HWND = 0 if you process custom thread messages sent
>>>> by PostThreadMessage() (just to be sure).
>>>
>>> Already doing this.
>>>
>>>>
>>>>
>>>>
>>>>> Regards,
>>>>>
>>>>> SZ
>>>>>
>>>>> - Original Message -
>>>>> From: "Wilfried Mestdagh" <[EMAIL PROTECTED]>
>>>>> To: "ICS support mailing"
>>>>> Sent: Tuesday, February 06, 2007 10:17 PM
>>>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> It is just a simple constant, why shouldn't it be 800 instead of
>>>>>>> 100??
>>>>>>
>>>>>> Because it is not the source of a bug. No need to change anything
>>>>>> if it is not buggy. Changing it and then your code works does not
>>>>>> prove there is a bug.
>>>>>>
>>>>>> ---
>>>>>> Rgds, Wilfried [TeamICS]
>>>>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>>>> http://www.mestdagh.biz
>>>>>>
>>>>>> --
>>>>>> 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
Re: [twsocket] Possible bug and solution in TWndControl
Arno,
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Wednesday, February 07, 2007 2:43 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Fastream Technologies wrote:
>
>> I did not understand what you propose to have a single wndhandler per
>> thread with messages starting from WM_APP + 100--how to do it
>> properly?
>
> As we discussed yesterday, increase value of constant WH_MAX_MSG,
> the higher the value the less windows will be created but performance
> may decrease. An option to _force_ only one single window is not
> available in the component. Initialize global variable GWndHandlerMsgLow
> to change the base of allocated message numbers.
I believe you are not getting all of my messages (I cannot exactly see them
since I am using Gmail and Gmail blocks the messages I send to mailing
lists). Anyway, the WM_USER + 1 is hard coded:
I traced the bug to here:
function TIcsWndHandlerPool.GetWndHandler(
HandlerCount : UINT;
ThreadID : THandle) : TIcsWndHandler;
var
I : Integer;
L : TIcsWndHandlerList;
begin
// Search the list which has same thread ID
I := FList.Count - 1;
while (I >= 0) and
(TIcsWndHandlerList(FList.Items[I]).ThreadID <> ThreadID) do
Dec(I);
if I >= 0 then
L := TIcsWndHandlerList(FList.Items[I])
else begin
// No list found. Create a new one
L := TIcsWndHandlerList.Create;
L.ThreadID := ThreadID;
FList.Add(L);
end;
// Search the list for a WndHandler with enough MsgHandlers available
I := 0;
while I < L.Count do begin
Result := TIcsWndHandler(L.Items[I]);
if Result.GetMsgLeft >= HandlerCount then
Exit;
Inc(I);
end;
Result:= TIcsWndHandler.Create;
Result.FOwnerList := L;
OutputDebugString(PChar('TIcsWndHandler.Create OwnerList = ' +
IntToHex(Integer(Result.FOwnerList), 8)));
Result.MsgLow := WM_USER + 1; // The EIP comes here, does not use my
wndhandler in thread!
L.Add(Result);
end;
This occurs in threadattach in the thread code I sent!
Best Regards,
SZ
>
> Why do you want to debug and tune all at the same time? Usually
> I start tweaking (known) parameters once the app. runs stable
> with default settings.
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
>>>
>>> And check for HWND = 0 if you process custom thread messages sent by
>>> PostThreadMessage() (just to be sure).
>>
>> Already doing this.
>>
>>>
>>>
>>>
>>>> Regards,
>>>>
>>>> SZ
>>>>
>>>> - Original Message -
>>>> From: "Wilfried Mestdagh" <[EMAIL PROTECTED]>
>>>> To: "ICS support mailing"
>>>> Sent: Tuesday, February 06, 2007 10:17 PM
>>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>>> It is just a simple constant, why shouldn't it be 800 instead of
>>>>>> 100??
>>>>>
>>>>> Because it is not the source of a bug. No need to change anything
>>>>> if it is not buggy. Changing it and then your code works does not
>>>>> prove there is a bug.
>>>>>
>>>>> ---
>>>>> Rgds, Wilfried [TeamICS]
>>>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>>> http://www.mestdagh.biz
>>>>>
>>>>> --
>>>>> 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
Re: [twsocket] Possible bug and solution in TWndControl
Fastream Technologies wrote: > I did not understand what you propose to have a single wndhandler per > thread with messages starting from WM_APP + 100--how to do it > properly? As we discussed yesterday, increase value of constant WH_MAX_MSG, the higher the value the less windows will be created but performance may decrease. An option to _force_ only one single window is not available in the component. Initialize global variable GWndHandlerMsgLow to change the base of allocated message numbers. Why do you want to debug and tune all at the same time? Usually I start tweaking (known) parameters once the app. runs stable with default settings. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html >> >> And check for HWND = 0 if you process custom thread messages sent by >> PostThreadMessage() (just to be sure). > > Already doing this. > >> >> >> >>> Regards, >>> >>> SZ >>> >>> - Original Message - >>> From: "Wilfried Mestdagh" <[EMAIL PROTECTED]> >>> To: "ICS support mailing" >>> Sent: Tuesday, February 06, 2007 10:17 PM >>> Subject: Re: [twsocket] Possible bug and solution in TWndControl >>> >>> >>>> Hi, >>>> >>>>> It is just a simple constant, why shouldn't it be 800 instead of >>>>> 100?? >>>> >>>> Because it is not the source of a bug. No need to change anything >>>> if it is not buggy. Changing it and then your code works does not >>>> prove there is a bug. >>>> >>>> --- >>>> Rgds, Wilfried [TeamICS] >>>> http://www.overbyte.be/eng/overbyte/teamics.html >>>> http://www.mestdagh.biz >>>> >>>> -- >>>> 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
Re: [twsocket] Possible bug and solution in TWndControl
- Original Message - From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Wednesday, February 07, 2007 10:51 AM Subject: Re: [twsocket] Possible bug and solution in TWndControl > Fastream Technologies wrote: >> Ok. Then there is a bug in ThreadAttach/Detach which Arno said he did >> not test against. Because my code is so simple! It just has three >> custom messages in WM_USER + 100-103 and the ICS messages are in >> WM_APP + 100. The only possibility is that my init code in the client >> thread is bad (see the first message of the thread). > >> TIcsWndHandler *windowHandler = new TIcsWndHandler(); >> windowHandler->MsgLow = WM_APP + 100; > > I don't see the deeper sence in these lines. > In order to set MsgLow initialize variable GWndHandlerMsgLow as > I already wrote in one of my first mails. I did not understand what you propose to have a single wndhandler per thread with messages starting from WM_APP + 100--how to do it properly? > > And check for HWND = 0 if you process custom thread messages sent by > PostThreadMessage() (just to be sure). Already doing this. > > > >> Regards, >> >> SZ >> >> - Original Message - >> From: "Wilfried Mestdagh" <[EMAIL PROTECTED]> >> To: "ICS support mailing" >> Sent: Tuesday, February 06, 2007 10:17 PM >> Subject: Re: [twsocket] Possible bug and solution in TWndControl >> >> >>> Hi, >>> >>>> It is just a simple constant, why shouldn't it be 800 instead of >>>> 100?? >>> >>> Because it is not the source of a bug. No need to change anything if >>> it is not buggy. Changing it and then your code works does not prove >>> there is a bug. >>> >>> --- >>> Rgds, Wilfried [TeamICS] >>> http://www.overbyte.be/eng/overbyte/teamics.html >>> http://www.mestdagh.biz >>> >>> -- >>> 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
Re: [twsocket] Possible bug and solution in TWndControl
Fastream Technologies wrote: > Ok. Then there is a bug in ThreadAttach/Detach which Arno said he did > not test against. Because my code is so simple! It just has three > custom messages in WM_USER + 100-103 and the ICS messages are in > WM_APP + 100. The only possibility is that my init code in the client > thread is bad (see the first message of the thread). > TIcsWndHandler *windowHandler = new TIcsWndHandler(); > windowHandler->MsgLow = WM_APP + 100; I don't see the deeper sence in these lines. In order to set MsgLow initialize variable GWndHandlerMsgLow as I already wrote in one of my first mails. And check for HWND = 0 if you process custom thread messages sent by PostThreadMessage() (just to be sure). > Regards, > > SZ > > - Original Message - > From: "Wilfried Mestdagh" <[EMAIL PROTECTED]> > To: "ICS support mailing" > Sent: Tuesday, February 06, 2007 10:17 PM > Subject: Re: [twsocket] Possible bug and solution in TWndControl > > >> Hi, >> >>> It is just a simple constant, why shouldn't it be 800 instead of >>> 100?? >> >> Because it is not the source of a bug. No need to change anything if >> it is not buggy. Changing it and then your code works does not prove >> there is a bug. >> >> --- >> Rgds, Wilfried [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> http://www.mestdagh.biz >> >> -- >> 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] Possible bug and solution in TWndControl
Hello,
I traced the bug to here:
function TIcsWndHandlerPool.GetWndHandler(
HandlerCount : UINT;
ThreadID : THandle) : TIcsWndHandler;
var
I : Integer;
L : TIcsWndHandlerList;
begin
// Search the list which has same thread ID
I := FList.Count - 1;
while (I >= 0) and
(TIcsWndHandlerList(FList.Items[I]).ThreadID <> ThreadID) do
Dec(I);
if I >= 0 then
L := TIcsWndHandlerList(FList.Items[I])
else begin
// No list found. Create a new one
L := TIcsWndHandlerList.Create;
L.ThreadID := ThreadID;
FList.Add(L);
end;
// Search the list for a WndHandler with enough MsgHandlers available
I := 0;
while I < L.Count do begin
Result := TIcsWndHandler(L.Items[I]);
if Result.GetMsgLeft >= HandlerCount then
Exit;
Inc(I);
end;
Result:= TIcsWndHandler.Create;
Result.FOwnerList := L;
OutputDebugString(PChar('TIcsWndHandler.Create OwnerList = ' +
IntToHex(Integer(Result.FOwnerList), 8)));
Result.MsgLow := WM_USER + 1; // The EIP comes here, does not use my
wndhandler in thread!
L.Add(Result);
end;
This occurs in threadattach in the thread code I sent!
Best Regards,
SZ
- Original Message -
From: "Wilfried Mestdagh" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Tuesday, February 06, 2007 10:17 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Hi,
>
>> It is just a simple constant, why shouldn't it be 800 instead of 100??
>
> Because it is not the source of a bug. No need to change anything if it
> is not buggy. Changing it and then your code works does not prove there
> is a bug.
>
> ---
> Rgds, Wilfried [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
> http://www.mestdagh.biz
>
> --
> 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] Possible bug and solution in TWndControl
Ok. Then there is a bug in ThreadAttach/Detach which Arno said he did not test against. Because my code is so simple! It just has three custom messages in WM_USER + 100-103 and the ICS messages are in WM_APP + 100. The only possibility is that my init code in the client thread is bad (see the first message of the thread). Regards, SZ - Original Message - From: "Wilfried Mestdagh" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Tuesday, February 06, 2007 10:17 PM Subject: Re: [twsocket] Possible bug and solution in TWndControl > Hi, > >> It is just a simple constant, why shouldn't it be 800 instead of 100?? > > Because it is not the source of a bug. No need to change anything if it > is not buggy. Changing it and then your code works does not prove there > is a bug. > > --- > Rgds, Wilfried [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > http://www.mestdagh.biz > > -- > 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] Possible bug and solution in TWndControl
Hi, > It is just a simple constant, why shouldn't it be 800 instead of 100?? Because it is not the source of a bug. No need to change anything if it is not buggy. Changing it and then your code works does not prove there is a bug. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- 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] Possible bug and solution in TWndControl
> I think Francois knows why he choosed 100 as the limit.
This is completely arbitrary. Too much messages means less performance. Too
less messages means too much windows. There is a tradeoff each one could
adjust to his needs.
--
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"
Sent: Tuesday, February 06, 2007 4:20 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Fastream Technologies wrote:
>> Despite all have been said, I still think that 100 messages/thread is
>> low.
>> It should be at least 400-600.
>
> WH_MAX_MSG does not specify the maximum possible number of messages
> in a thread but maximum messages handled by a single hidden window
> before a new window will be created. Let's assume TWSocket requires
> 12 message numbers the one hidden window could handle 96 message
> numbers or 8 different instances of TWSocket created in the same
> thread. 80 instances would create 10 hidden windows. I think
> Francois knows why he choosed 100 as the limit.
>
> While writing this it comes to my mind that you might not have
> overridden MsgHandlersCount correctly. Each custom message that is
> registered by AllocateMsgHandlers() must increment MsgHandlersCount
> as well as need to be unregistered by FWndHandler.UnregisterMessage.
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
>> Regards,
>>
>> SZ
>>
>> - Original Message -
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Tuesday, February 06, 2007 2:39 PM
>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>
>>
>>> What about using RegisterWindowMessage to let windows give you a
>>> value for
>>> the windows-message not beeing in use?
>>
>> Messages are sent/posted either to a unique window handle
>> or to a unique thread-ID so the message numbers must neither
>> be unique in the application nor in the system. Commonly you
>> would receive 'ghost' messages only if the own application
>> sent/posted messages to the hidden component window with a
>> message number not previously registered and mapped by
>> AllocateMsgHandler() in the right thread.
>> AFAIK BroadcastSystemMessage() can be called with messages
>> registered by RegisterWindowMessage() only. So if there's
>> no bad application explicitely spying for the hidden window
>> and sending it a message that ICS handles everything
>> should work just fine, no difference to V5. Third party
>> components and their message numbers should not conflict
>> (my previous email was probably a bit confusing).
>>
>> Finally there may be a bug in V6, but so far I think this
>> chance is very low, since I've been playing with and stress
>> tested a multi-threaded V6 server back in 2006 and I had no
>> such problems with message numbers at all, my server did not
>> call ThreadDetach/ThreadAttach but used a pool of TWSocket
>> clients allocated and managed in each thread. My guess is
>> that SZ still has synchronization bug(s) in his multi-threaded
>> application that cause strange, subsequent errors. Anyway
>> hard to debug.
>>
>> ---
>> Arno Garrels [TeamICS]
>> http://www.overbyte.be/eng/overbyte/teamics.html
>>
>>
>> Bjørnar Nielsen wrote:
>>> What about using RegisterWindowMessage to let windows give you a
>>> value for
>>> the windows-message not beeing in use? Usually this procedure is used
>>> when
>>> sending windows messages between applications. But I don't see a
>>> reason for
>>> not using this inside the application also. If we give the windows
>>> message a
>>> name that is safe to assume that no other application would use, then
>>> we
>>> would have a message that no other applications/librarys use.
>>>
>>> For those not familiar with this procedure, this is how it works:
>>> const int MY_CUSTOM_MESSAGE =
>>> RegisterWindowMessage("MY_CUSTOM_MESSAGE");
>>>
>>> The first time this is called after a reboot, windows will reserve a
>>> value
>>> for the message-name and return it. The next time the procedure is
>>> called
>>> with the same string, it will return the same value as earlier.
>>>
>>> Regards Bjørnar
>>>
>>>> I still recommend
Re: [twsocket] Possible bug and solution in TWndControl
> BTW, where is Francois??
I'm here but working on a big contract.
Sorry but free support is given after everything else is done.
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Fastream Technologies" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Tuesday, February 06, 2007 5:13 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Hello Arno,
>
> I am not sure I understand how could more window handles in a single
> thread
> would benefit than single window handle! BTW, where is Francois??
>
> Best Regards,
>
> SZ
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Tuesday, February 06, 2007 5:20 PM
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
>
> Fastream Technologies wrote:
>> Despite all have been said, I still think that 100 messages/thread is
>> low.
>> It should be at least 400-600.
>
> WH_MAX_MSG does not specify the maximum possible number of messages
> in a thread but maximum messages handled by a single hidden window
> before a new window will be created. Let's assume TWSocket requires
> 12 message numbers the one hidden window could handle 96 message
> numbers or 8 different instances of TWSocket created in the same
> thread. 80 instances would create 10 hidden windows. I think
> Francois knows why he choosed 100 as the limit.
>
> While writing this it comes to my mind that you might not have
> overridden MsgHandlersCount correctly. Each custom message that is
> registered by AllocateMsgHandlers() must increment MsgHandlersCount
> as well as need to be unregistered by FWndHandler.UnregisterMessage.
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
>> Regards,
>>
>> SZ
>>
>> - Original Message -
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Tuesday, February 06, 2007 2:39 PM
>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>
>>
>>> What about using RegisterWindowMessage to let windows give you a
>>> value for
>>> the windows-message not beeing in use?
>>
>> Messages are sent/posted either to a unique window handle
>> or to a unique thread-ID so the message numbers must neither
>> be unique in the application nor in the system. Commonly you
>> would receive 'ghost' messages only if the own application
>> sent/posted messages to the hidden component window with a
>> message number not previously registered and mapped by
>> AllocateMsgHandler() in the right thread.
>> AFAIK BroadcastSystemMessage() can be called with messages
>> registered by RegisterWindowMessage() only. So if there's
>> no bad application explicitely spying for the hidden window
>> and sending it a message that ICS handles everything
>> should work just fine, no difference to V5. Third party
>> components and their message numbers should not conflict
>> (my previous email was probably a bit confusing).
>>
>> Finally there may be a bug in V6, but so far I think this
>> chance is very low, since I've been playing with and stress
>> tested a multi-threaded V6 server back in 2006 and I had no
>> such problems with message numbers at all, my server did not
>> call ThreadDetach/ThreadAttach but used a pool of TWSocket
>> clients allocated and managed in each thread. My guess is
>> that SZ still has synchronization bug(s) in his multi-threaded
>> application that cause strange, subsequent errors. Anyway
>> hard to debug.
>>
>> ---
>> Arno Garrels [TeamICS]
>> http://www.overbyte.be/eng/overbyte/teamics.html
>>
>>
>> Bjørnar Nielsen wrote:
>>> What about using RegisterWindowMessage to let windows give you a
>>> value for
>>> the windows-message not beeing in use? Usually this procedure is used
>>> when
>>> sending windows messages between applications. But I don't see a
>>> reason for
>>> not using this inside the application also. If we give the windows
>>> message a
>>> name that is safe to assume that no other application would use, then
>>> we
>>> would have a message that no other applications/librarys use.
>>>
>>> For those not familiar with this procedure, this is how it works:
>>> const int MY_CUSTOM_MESSAGE =
>>> RegisterWindowMessage("MY_CUSTOM_ME
Re: [twsocket] Possible bug and solution in TWndControl
Fastream Technologies wrote:
> Hello Arno,
>
> I am not sure I understand how could more window handles in a single
> thread
> would benefit than single window handle!
There is for instance a bigger static array [0..WH_MAX_MSG]
of TIcsWndControl.. I would play with the value and find
an optimal setting for my application. Only I do not believe
that it fixed the root of your ghost-message-problem.
> BTW, where is Francois??
AFAIK he's currently very busy.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
>
> Best Regards,
>
> SZ
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Tuesday, February 06, 2007 5:20 PM
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
>
> Fastream Technologies wrote:
>> Despite all have been said, I still think that 100 messages/thread is
>> low.
>> It should be at least 400-600.
>
> WH_MAX_MSG does not specify the maximum possible number of messages
> in a thread but maximum messages handled by a single hidden window
> before a new window will be created. Let's assume TWSocket requires
> 12 message numbers the one hidden window could handle 96 message
> numbers or 8 different instances of TWSocket created in the same
> thread. 80 instances would create 10 hidden windows. I think
> Francois knows why he choosed 100 as the limit.
>
> While writing this it comes to my mind that you might not have
> overridden MsgHandlersCount correctly. Each custom message that is
> registered by AllocateMsgHandlers() must increment MsgHandlersCount
> as well as need to be unregistered by FWndHandler.UnregisterMessage.
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
>> Regards,
>>
>> SZ
>>
>> ----- Original Message -
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Tuesday, February 06, 2007 2:39 PM
>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>
>>
>>> What about using RegisterWindowMessage to let windows give you a
>>> value for
>>> the windows-message not beeing in use?
>>
>> Messages are sent/posted either to a unique window handle
>> or to a unique thread-ID so the message numbers must neither
>> be unique in the application nor in the system. Commonly you
>> would receive 'ghost' messages only if the own application
>> sent/posted messages to the hidden component window with a
>> message number not previously registered and mapped by
>> AllocateMsgHandler() in the right thread.
>> AFAIK BroadcastSystemMessage() can be called with messages
>> registered by RegisterWindowMessage() only. So if there's
>> no bad application explicitely spying for the hidden window
>> and sending it a message that ICS handles everything
>> should work just fine, no difference to V5. Third party
>> components and their message numbers should not conflict
>> (my previous email was probably a bit confusing).
>>
>> Finally there may be a bug in V6, but so far I think this
>> chance is very low, since I've been playing with and stress
>> tested a multi-threaded V6 server back in 2006 and I had no
>> such problems with message numbers at all, my server did not
>> call ThreadDetach/ThreadAttach but used a pool of TWSocket
>> clients allocated and managed in each thread. My guess is
>> that SZ still has synchronization bug(s) in his multi-threaded
>> application that cause strange, subsequent errors. Anyway
>> hard to debug.
>>
>> ---
>> Arno Garrels [TeamICS]
>> http://www.overbyte.be/eng/overbyte/teamics.html
>>
>>
>> Bjørnar Nielsen wrote:
>>> What about using RegisterWindowMessage to let windows give you a
>>> value for
>>> the windows-message not beeing in use? Usually this procedure is
>>> used when
>>> sending windows messages between applications. But I don't see a
>>> reason for
>>> not using this inside the application also. If we give the windows
>>> message a
>>> name that is safe to assume that no other application would use,
>>> then we
>>> would have a message that no other applications/librarys use.
>>>
>>> For those not familiar with this procedure, this is how it works:
>>> const int MY_CUSTOM_MESSAGE =
>>> RegisterWindowMessage("MY_CUSTOM_MESSAGE");
>>>
>>> The first time this is called after a reboot, window
Re: [twsocket] Possible bug and solution in TWndControl
Hello Arno,
I am not sure I understand how could more window handles in a single thread
would benefit than single window handle! BTW, where is Francois??
Best Regards,
SZ
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Tuesday, February 06, 2007 5:20 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
Fastream Technologies wrote:
> Despite all have been said, I still think that 100 messages/thread is
> low.
> It should be at least 400-600.
WH_MAX_MSG does not specify the maximum possible number of messages
in a thread but maximum messages handled by a single hidden window
before a new window will be created. Let's assume TWSocket requires
12 message numbers the one hidden window could handle 96 message
numbers or 8 different instances of TWSocket created in the same
thread. 80 instances would create 10 hidden windows. I think
Francois knows why he choosed 100 as the limit.
While writing this it comes to my mind that you might not have
overridden MsgHandlersCount correctly. Each custom message that is
registered by AllocateMsgHandlers() must increment MsgHandlersCount
as well as need to be unregistered by FWndHandler.UnregisterMessage.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
> Regards,
>
> SZ
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Tuesday, February 06, 2007 2:39 PM
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
>
>> What about using RegisterWindowMessage to let windows give you a
>> value for
>> the windows-message not beeing in use?
>
> Messages are sent/posted either to a unique window handle
> or to a unique thread-ID so the message numbers must neither
> be unique in the application nor in the system. Commonly you
> would receive 'ghost' messages only if the own application
> sent/posted messages to the hidden component window with a
> message number not previously registered and mapped by
> AllocateMsgHandler() in the right thread.
> AFAIK BroadcastSystemMessage() can be called with messages
> registered by RegisterWindowMessage() only. So if there's
> no bad application explicitely spying for the hidden window
> and sending it a message that ICS handles everything
> should work just fine, no difference to V5. Third party
> components and their message numbers should not conflict
> (my previous email was probably a bit confusing).
>
> Finally there may be a bug in V6, but so far I think this
> chance is very low, since I've been playing with and stress
> tested a multi-threaded V6 server back in 2006 and I had no
> such problems with message numbers at all, my server did not
> call ThreadDetach/ThreadAttach but used a pool of TWSocket
> clients allocated and managed in each thread. My guess is
> that SZ still has synchronization bug(s) in his multi-threaded
> application that cause strange, subsequent errors. Anyway
> hard to debug.
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
> Bjørnar Nielsen wrote:
>> What about using RegisterWindowMessage to let windows give you a
>> value for
>> the windows-message not beeing in use? Usually this procedure is used
>> when
>> sending windows messages between applications. But I don't see a
>> reason for
>> not using this inside the application also. If we give the windows
>> message a
>> name that is safe to assume that no other application would use, then
>> we
>> would have a message that no other applications/librarys use.
>>
>> For those not familiar with this procedure, this is how it works:
>> const int MY_CUSTOM_MESSAGE =
>> RegisterWindowMessage("MY_CUSTOM_MESSAGE");
>>
>> The first time this is called after a reboot, windows will reserve a
>> value
>> for the message-name and return it. The next time the procedure is
>> called
>> with the same string, it will return the same value as earlier.
>>
>> Regards Bjørnar
>>
>>> I still recommend to find the sender of that anonymous
>>> message as well as find a reliable range of message numbers
>>> that can be used by ICS V6 exclusively. Who knows whether
>>> there is still a strange third party message being processed
>>> that you do not note because it simply doesn't raise the test
>>> exception but triggers a ICS event? In other words I always
>>> would try to find the root of the problem.
> --
> 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
Re: [twsocket] Possible bug and solution in TWndControl
Fastream Technologies wrote:
> Despite all have been said, I still think that 100 messages/thread is
> low.
> It should be at least 400-600.
WH_MAX_MSG does not specify the maximum possible number of messages
in a thread but maximum messages handled by a single hidden window
before a new window will be created. Let's assume TWSocket requires
12 message numbers the one hidden window could handle 96 message
numbers or 8 different instances of TWSocket created in the same
thread. 80 instances would create 10 hidden windows. I think
Francois knows why he choosed 100 as the limit.
While writing this it comes to my mind that you might not have
overridden MsgHandlersCount correctly. Each custom message that is
registered by AllocateMsgHandlers() must increment MsgHandlersCount
as well as need to be unregistered by FWndHandler.UnregisterMessage.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
> Regards,
>
> SZ
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Tuesday, February 06, 2007 2:39 PM
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
>
>> What about using RegisterWindowMessage to let windows give you a
>> value for
>> the windows-message not beeing in use?
>
> Messages are sent/posted either to a unique window handle
> or to a unique thread-ID so the message numbers must neither
> be unique in the application nor in the system. Commonly you
> would receive 'ghost' messages only if the own application
> sent/posted messages to the hidden component window with a
> message number not previously registered and mapped by
> AllocateMsgHandler() in the right thread.
> AFAIK BroadcastSystemMessage() can be called with messages
> registered by RegisterWindowMessage() only. So if there's
> no bad application explicitely spying for the hidden window
> and sending it a message that ICS handles everything
> should work just fine, no difference to V5. Third party
> components and their message numbers should not conflict
> (my previous email was probably a bit confusing).
>
> Finally there may be a bug in V6, but so far I think this
> chance is very low, since I've been playing with and stress
> tested a multi-threaded V6 server back in 2006 and I had no
> such problems with message numbers at all, my server did not
> call ThreadDetach/ThreadAttach but used a pool of TWSocket
> clients allocated and managed in each thread. My guess is
> that SZ still has synchronization bug(s) in his multi-threaded
> application that cause strange, subsequent errors. Anyway
> hard to debug.
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
> Bjørnar Nielsen wrote:
>> What about using RegisterWindowMessage to let windows give you a
>> value for
>> the windows-message not beeing in use? Usually this procedure is used
>> when
>> sending windows messages between applications. But I don't see a
>> reason for
>> not using this inside the application also. If we give the windows
>> message a
>> name that is safe to assume that no other application would use, then
>> we
>> would have a message that no other applications/librarys use.
>>
>> For those not familiar with this procedure, this is how it works:
>> const int MY_CUSTOM_MESSAGE =
>> RegisterWindowMessage("MY_CUSTOM_MESSAGE");
>>
>> The first time this is called after a reboot, windows will reserve a
>> value
>> for the message-name and return it. The next time the procedure is
>> called
>> with the same string, it will return the same value as earlier.
>>
>> Regards Bjørnar
>>
>>> I still recommend to find the sender of that anonymous
>>> message as well as find a reliable range of message numbers
>>> that can be used by ICS V6 exclusively. Who knows whether
>>> there is still a strange third party message being processed
>>> that you do not note because it simply doesn't raise the test
>>> exception but triggers a ICS event? In other words I always
>>> would try to find the root of the problem.
> --
> 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] Possible bug and solution in TWndControl
Despite all have been said, I still think that 100 messages/thread is low.
It should be at least 400-600.
Regards,
SZ
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Tuesday, February 06, 2007 2:39 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> What about using RegisterWindowMessage to let windows give you a
> value for
> the windows-message not beeing in use?
Messages are sent/posted either to a unique window handle
or to a unique thread-ID so the message numbers must neither
be unique in the application nor in the system. Commonly you
would receive 'ghost' messages only if the own application
sent/posted messages to the hidden component window with a
message number not previously registered and mapped by
AllocateMsgHandler() in the right thread.
AFAIK BroadcastSystemMessage() can be called with messages
registered by RegisterWindowMessage() only. So if there's
no bad application explicitely spying for the hidden window
and sending it a message that ICS handles everything
should work just fine, no difference to V5. Third party
components and their message numbers should not conflict
(my previous email was probably a bit confusing).
Finally there may be a bug in V6, but so far I think this
chance is very low, since I've been playing with and stress
tested a multi-threaded V6 server back in 2006 and I had no
such problems with message numbers at all, my server did not
call ThreadDetach/ThreadAttach but used a pool of TWSocket
clients allocated and managed in each thread. My guess is
that SZ still has synchronization bug(s) in his multi-threaded
application that cause strange, subsequent errors. Anyway
hard to debug.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
Bjørnar Nielsen wrote:
> What about using RegisterWindowMessage to let windows give you a
> value for
> the windows-message not beeing in use? Usually this procedure is used
> when
> sending windows messages between applications. But I don't see a
> reason for
> not using this inside the application also. If we give the windows
> message a
> name that is safe to assume that no other application would use, then
> we
> would have a message that no other applications/librarys use.
>
> For those not familiar with this procedure, this is how it works:
> const int MY_CUSTOM_MESSAGE =
> RegisterWindowMessage("MY_CUSTOM_MESSAGE");
>
> The first time this is called after a reboot, windows will reserve a
> value
> for the message-name and return it. The next time the procedure is
> called
> with the same string, it will return the same value as earlier.
>
> Regards Bjørnar
>
>> I still recommend to find the sender of that anonymous
>> message as well as find a reliable range of message numbers
>> that can be used by ICS V6 exclusively. Who knows whether
>> there is still a strange third party message being processed
>> that you do not note because it simply doesn't raise the test
>> exception but triggers a ICS event? In other words I always
>> would try to find the root of the problem.
--
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] Possible bug and solution in TWndControl
> What about using RegisterWindowMessage to let windows give you a
> value for
> the windows-message not beeing in use?
Messages are sent/posted either to a unique window handle
or to a unique thread-ID so the message numbers must neither
be unique in the application nor in the system. Commonly you
would receive 'ghost' messages only if the own application
sent/posted messages to the hidden component window with a
message number not previously registered and mapped by
AllocateMsgHandler() in the right thread.
AFAIK BroadcastSystemMessage() can be called with messages
registered by RegisterWindowMessage() only. So if there's
no bad application explicitely spying for the hidden window
and sending it a message that ICS handles everything
should work just fine, no difference to V5. Third party
components and their message numbers should not conflict
(my previous email was probably a bit confusing).
Finally there may be a bug in V6, but so far I think this
chance is very low, since I've been playing with and stress
tested a multi-threaded V6 server back in 2006 and I had no
such problems with message numbers at all, my server did not
call ThreadDetach/ThreadAttach but used a pool of TWSocket
clients allocated and managed in each thread. My guess is
that SZ still has synchronization bug(s) in his multi-threaded
application that cause strange, subsequent errors. Anyway
hard to debug.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
Bjørnar Nielsen wrote:
> What about using RegisterWindowMessage to let windows give you a
> value for
> the windows-message not beeing in use? Usually this procedure is used
> when
> sending windows messages between applications. But I don't see a
> reason for
> not using this inside the application also. If we give the windows
> message a
> name that is safe to assume that no other application would use, then
> we
> would have a message that no other applications/librarys use.
>
> For those not familiar with this procedure, this is how it works:
> const int MY_CUSTOM_MESSAGE =
> RegisterWindowMessage("MY_CUSTOM_MESSAGE");
>
> The first time this is called after a reboot, windows will reserve a
> value
> for the message-name and return it. The next time the procedure is
> called
> with the same string, it will return the same value as earlier.
>
> Regards Bjørnar
>
>> I still recommend to find the sender of that anonymous
>> message as well as find a reliable range of message numbers
>> that can be used by ICS V6 exclusively. Who knows whether
>> there is still a strange third party message being processed
>> that you do not note because it simply doesn't raise the test
>> exception but triggers a ICS event? In other words I always
>> would try to find the root of the problem.
--
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] Possible bug and solution in TWndControl
What about using RegisterWindowMessage to let windows give you a value for
the windows-message not beeing in use? Usually this procedure is used when
sending windows messages between applications. But I don't see a reason for
not using this inside the application also. If we give the windows message a
name that is safe to assume that no other application would use, then we
would have a message that no other applications/librarys use.
For those not familiar with this procedure, this is how it works:
const int MY_CUSTOM_MESSAGE = RegisterWindowMessage("MY_CUSTOM_MESSAGE");
The first time this is called after a reboot, windows will reserve a value
for the message-name and return it. The next time the procedure is called
with the same string, it will return the same value as earlier.
Regards Bjørnar
> I still recommend to find the sender of that anonymous
> message as well as find a reliable range of message numbers
> that can be used by ICS V6 exclusively. Who knows whether
> there is still a strange third party message being processed
> that you do not note because it simply doesn't raise the test
> exception but triggers a ICS event? In other words I always
> would try to find the root of the problem.
--
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] Possible bug and solution in TWndControl
Fastream Technologies wrote: > Arno, > > There is a TWndControl in the worker thread context which is created > before clients are threadattach'ed to the thread (in a custom message > handler). I still recommend to find the sender of that anonymous message as well as find a reliable range of message numbers that can be used by ICS V6 exclusively. Who knows whether there is still a strange third party message being processed that you do not note because it simply doesn't raise the test exception but triggers a ICS event? In other words I always would try to find the root of the problem. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > > Regards, > > SZ > > - Original Message - > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" > Sent: Monday, February 05, 2007 5:57 PM > Subject: Re: [twsocket] Possible bug and solution in TWndControl > > >> Fastream Technologies wrote: >>> Yoiu also missed that this is a service application thread with no >>> other component than ICS! Even no GUI. I am unable to find the bug-- >>> there is one I know but it happens under heavy load and does not >>> show its ugly head under Debug compilation. >>> >>> It is just a simple constant, why shouldn't it be 800 instead of >>> 100?? >> >> You can, but I fear it doesn't _solve the problem finally. >> >> If you set property MsgLow like: >> >> WSocket1 := TWSocket.Create(something); >> WSocket1.MsgLow := WM_APP + 100; >> >> strange things will happen, including AVs in >> TIcsWndHandler.UnregisterMessage. Because some message numbers >> are already assigned with default numbers (base WM_USER) before the >> new value of property MsgLow will be set. >> >> Instead initialize global variable GWndHandlerMsgLow in an >> Initialization section in project unit. >> >> initialization >>GWndHandlerMsgLow := WM_APP + 100; >> >> I hope this helps. >> >> --- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >> >> >> >>> Regards, >>> >>> SZ >>> >>> - Original Message - >>> From: "Arno Garrels" <[EMAIL PROTECTED]> >>> To: "ICS support mailing" >>> Sent: Monday, February 05, 2007 3:47 PM >>> Subject: Re: [twsocket] Possible bug and solution in TWndControl >>> >>> >>>> Fastream Technologies wrote: >>>>> Yes these are all what I thought for a week time! I call >>>>> GetMessage, then check for known/my messages. If none of them, >>>>> call dispatchmessage and all works fine except the problem which >>>>> goes away if we set the WHG_MAX to 800 instead of 100! Now there >>>>> is no such exception thrown--tested with millions of connections. >>>> >>>> Ahh, I missed that you use WM_APP + 100, that's a range I would not >>>> use for window messages but something in the higher range of >>>> WM_USER instead. >>>> >>>> It's strange anyway that increasing the maximum number of messages >>>> made the error went away since that shouldn't change the base >>>> number and range. >>>> >>>> However here is a quick text-search in my component folder >>>> >>>> VirtualTreeview: >>>> WM_CHANGESTATE = WM_APP + 32; >>>> >>>> >>>> VShellTools: >>>> WM_NEWINPUT = WM_APP + 111; >>>> WM_SHELLNOTIFY = WM_APP + 51; // Change in the Shell occured >>>> WM_REMOVEBUTTON = WM_APP + 8; // VirtualShellToolbar >>>> WM_CHANGENOTIFY_CUSTOM = WM_APP + 9; >>>> WM_UPDATESCROLLBAR = WM_APP + 10; >>>> WM_VETBASE = WM_APP + 100 >>>> >>>> and more.. >>>> So be carefull and find the sender!! >>>> >>>> --- >>>> Arno Garrels [TeamICS] >>>> http://www.overbyte.be/eng/overbyte/teamics.html >>>> >>>> >>>> >>>> >>>>> >>>>> Francois, will you? >>>>> >>>>> Best Regards, >>>>> >>>>> SZ >>>>> >>>>> - Original Message - >>>>> From: "Arno Garrels" <[EMAIL PROTECTED]> >>>>> To: "ICS support mailing" >>>>> Sent: Monday, Febru
Re: [twsocket] Possible bug and solution in TWndControl
Arno, There is a TWndControl in the worker thread context which is created before clients are threadattach'ed to the thread (in a custom message handler). Regards, SZ - Original Message - From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Monday, February 05, 2007 5:57 PM Subject: Re: [twsocket] Possible bug and solution in TWndControl > Fastream Technologies wrote: >> Yoiu also missed that this is a service application thread with no >> other component than ICS! Even no GUI. I am unable to find the bug-- >> there is one I know but it happens under heavy load and does not show >> its ugly head under Debug compilation. >> >> It is just a simple constant, why shouldn't it be 800 instead of 100?? > > You can, but I fear it doesn't _solve the problem finally. > > If you set property MsgLow like: > > WSocket1 := TWSocket.Create(something); > WSocket1.MsgLow := WM_APP + 100; > > strange things will happen, including AVs in > TIcsWndHandler.UnregisterMessage. Because some message numbers > are already assigned with default numbers (base WM_USER) before the > new value of property MsgLow will be set. > > Instead initialize global variable GWndHandlerMsgLow in an > Initialization section in project unit. > > initialization >GWndHandlerMsgLow := WM_APP + 100; > > I hope this helps. > > --- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > > > >> Regards, >> >> SZ >> >> - Original Message - >> From: "Arno Garrels" <[EMAIL PROTECTED]> >> To: "ICS support mailing" >> Sent: Monday, February 05, 2007 3:47 PM >> Subject: Re: [twsocket] Possible bug and solution in TWndControl >> >> >>> Fastream Technologies wrote: >>>> Yes these are all what I thought for a week time! I call GetMessage, >>>> then check for known/my messages. If none of them, call >>>> dispatchmessage and all works fine except the problem which goes >>>> away if we set the WHG_MAX to 800 instead of 100! Now there is no >>>> such exception thrown--tested with millions of connections. >>> >>> Ahh, I missed that you use WM_APP + 100, that's a range I would not >>> use for window messages but something in the higher range of WM_USER >>> instead. >>> >>> It's strange anyway that increasing the maximum number of messages >>> made the error went away since that shouldn't change the base number >>> and range. >>> >>> However here is a quick text-search in my component folder >>> >>> VirtualTreeview: >>> WM_CHANGESTATE = WM_APP + 32; >>> >>> >>> VShellTools: >>> WM_NEWINPUT = WM_APP + 111; >>> WM_SHELLNOTIFY = WM_APP + 51; // Change in the Shell occured >>> WM_REMOVEBUTTON = WM_APP + 8; // VirtualShellToolbar >>> WM_CHANGENOTIFY_CUSTOM = WM_APP + 9; >>> WM_UPDATESCROLLBAR = WM_APP + 10; >>> WM_VETBASE = WM_APP + 100 >>> >>> and more.. >>> So be carefull and find the sender!! >>> >>> --- >>> Arno Garrels [TeamICS] >>> http://www.overbyte.be/eng/overbyte/teamics.html >>> >>> >>> >>> >>>> >>>> Francois, will you? >>>> >>>> Best Regards, >>>> >>>> SZ >>>> >>>> - Original Message - >>>> From: "Arno Garrels" <[EMAIL PROTECTED]> >>>> To: "ICS support mailing" >>>> Sent: Monday, February 05, 2007 1:50 PM >>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl >>>> >>>> >>>>>>> This is probably because you post custom messages do you? >>>>>> >>>>>> Yes but they are starting from WM_USER and there are only 4 of >>>>>> them in this thread. According to help, WM_USER starts from >>>>>> 0x0800 and there should be enough room until WM_APP+100. >>>>> >>>>> But there must somebody send messages in that range. >>>>> >>>>> At first check whether you send any message to the hidden component >>>>> window that has not been registered thru a call to >>>>> WndHandler.AllocateMsgHandler(). >>>>> >>>>> Also, you can (should) use your own message pump in a thread, that >>>>> checks the HWND. >>>>> >>>>> if msg.
Re: [twsocket] Possible bug and solution in TWndControl
Fastream Technologies wrote:
> Yoiu also missed that this is a service application thread with no
> other component than ICS! Even no GUI. I am unable to find the bug--
> there is one I know but it happens under heavy load and does not show
> its ugly head under Debug compilation.
>
> It is just a simple constant, why shouldn't it be 800 instead of 100??
You can, but I fear it doesn't _solve the problem finally.
If you set property MsgLow like:
WSocket1 := TWSocket.Create(something);
WSocket1.MsgLow := WM_APP + 100;
strange things will happen, including AVs in
TIcsWndHandler.UnregisterMessage. Because some message numbers
are already assigned with default numbers (base WM_USER) before the
new value of property MsgLow will be set.
Instead initialize global variable GWndHandlerMsgLow in an
Initialization section in project unit.
initialization
GWndHandlerMsgLow := WM_APP + 100;
I hope this helps.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
> Regards,
>
> SZ
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Monday, February 05, 2007 3:47 PM
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
>
>> Fastream Technologies wrote:
>>> Yes these are all what I thought for a week time! I call GetMessage,
>>> then check for known/my messages. If none of them, call
>>> dispatchmessage and all works fine except the problem which goes
>>> away if we set the WHG_MAX to 800 instead of 100! Now there is no
>>> such exception thrown--tested with millions of connections.
>>
>> Ahh, I missed that you use WM_APP + 100, that's a range I would not
>> use for window messages but something in the higher range of WM_USER
>> instead.
>>
>> It's strange anyway that increasing the maximum number of messages
>> made the error went away since that shouldn't change the base number
>> and range.
>>
>> However here is a quick text-search in my component folder
>>
>> VirtualTreeview:
>> WM_CHANGESTATE = WM_APP + 32;
>>
>>
>> VShellTools:
>> WM_NEWINPUT = WM_APP + 111;
>> WM_SHELLNOTIFY = WM_APP + 51; // Change in the Shell occured
>> WM_REMOVEBUTTON = WM_APP + 8; // VirtualShellToolbar
>> WM_CHANGENOTIFY_CUSTOM = WM_APP + 9;
>> WM_UPDATESCROLLBAR = WM_APP + 10;
>> WM_VETBASE = WM_APP + 100
>>
>> and more..
>> So be carefull and find the sender!!
>>
>> ---
>> Arno Garrels [TeamICS]
>> http://www.overbyte.be/eng/overbyte/teamics.html
>>
>>
>>
>>
>>>
>>> Francois, will you?
>>>
>>> Best Regards,
>>>
>>> SZ
>>>
>>> - Original Message -
>>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>>> To: "ICS support mailing"
>>> Sent: Monday, February 05, 2007 1:50 PM
>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>>
>>>
>>>>>> This is probably because you post custom messages do you?
>>>>>
>>>>> Yes but they are starting from WM_USER and there are only 4 of
>>>>> them in this thread. According to help, WM_USER starts from
>>>>> 0x0800 and there should be enough room until WM_APP+100.
>>>>
>>>> But there must somebody send messages in that range.
>>>>
>>>> At first check whether you send any message to the hidden component
>>>> window that has not been registered thru a call to
>>>> WndHandler.AllocateMsgHandler().
>>>>
>>>> Also, you can (should) use your own message pump in a thread, that
>>>> checks the HWND.
>>>>
>>>> if msg.hwnd = 0 then { Thread message }
>>>> begin
>>>> Any message that was posted to this thread goes here.
>>>> In this case you may even PostThreadMessages with message numbers
>>>> in the range of ICS messages.
>>>> end
>>>> else
>>>> Not a thread message, receiver is a window
>>>>
>>>> ---
>>>> Arno Garrels [TeamICS]
>>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Fastream Technologies wrote:
>>>>> Hello Arno,
>>>>>
>>>>> - Original Message -
>>>>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>>>>> To: "IC
Re: [twsocket] Possible bug and solution in TWndControl
Yoiu also missed that this is a service application thread with no other
component than ICS! Even no GUI. I am unable to find the bug--there is one I
know but it happens under heavy load and does not show its ugly head under
Debug compilation.
It is just a simple constant, why shouldn't it be 800 instead of 100??
Regards,
SZ
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Monday, February 05, 2007 3:47 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Fastream Technologies wrote:
>> Yes these are all what I thought for a week time! I call GetMessage,
>> then check for known/my messages. If none of them, call
>> dispatchmessage and all works fine except the problem which goes away
>> if we set the WHG_MAX to 800 instead of 100! Now there is no such
>> exception thrown--tested with millions of connections.
>
> Ahh, I missed that you use WM_APP + 100, that's a range I would not
> use for window messages but something in the higher range of WM_USER
> instead.
>
> It's strange anyway that increasing the maximum number of messages made
> the error went away since that shouldn't change the base number and range.
>
> However here is a quick text-search in my component folder
>
> VirtualTreeview:
> WM_CHANGESTATE = WM_APP + 32;
>
>
> VShellTools:
> WM_NEWINPUT = WM_APP + 111;
> WM_SHELLNOTIFY = WM_APP + 51; // Change in the Shell occured
> WM_REMOVEBUTTON = WM_APP + 8; // VirtualShellToolbar
> WM_CHANGENOTIFY_CUSTOM = WM_APP + 9;
> WM_UPDATESCROLLBAR = WM_APP + 10;
> WM_VETBASE = WM_APP + 100
>
> and more..
> So be carefull and find the sender!!
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
>
>
>>
>> Francois, will you?
>>
>> Best Regards,
>>
>> SZ
>>
>> - Original Message -
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Monday, February 05, 2007 1:50 PM
>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>
>>
>>>>> This is probably because you post custom messages do you?
>>>>
>>>> Yes but they are starting from WM_USER and there are only 4 of them
>>>> in this thread. According to help, WM_USER starts from 0x0800 and
>>>> there should be enough room until WM_APP+100.
>>>
>>> But there must somebody send messages in that range.
>>>
>>> At first check whether you send any message to the hidden component
>>> window that has not been registered thru a call to
>>> WndHandler.AllocateMsgHandler().
>>>
>>> Also, you can (should) use your own message pump in a thread, that
>>> checks the HWND.
>>>
>>> if msg.hwnd = 0 then { Thread message }
>>> begin
>>> Any message that was posted to this thread goes here.
>>> In this case you may even PostThreadMessages with message numbers
>>> in the range of ICS messages.
>>> end
>>> else
>>> Not a thread message, receiver is a window
>>>
>>> ---
>>> Arno Garrels [TeamICS]
>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>
>>>
>>>
>>>
>>>
>>> Fastream Technologies wrote:
>>>> Hello Arno,
>>>>
>>>> - Original Message -
>>>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>>>> To: "ICS support mailing"
>>>> Sent: Monday, February 05, 2007 1:24 PM
>>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>>>
>>>>
>>>>> Fastream Technologies wrote:
>>>>>> Hello,
>>>>>>
>>>>>> When I use the following thread code:
>>>>>>
>>>>>> void __fastcall ReverseProxyClientThread::Execute()
>>>>>> {
>>>>>> // Place thread code here
>>>>>> FreeOnTerminate = true;
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> TIcsWndHandler *windowHandler = new TIcsWndHandler();
>>>>>> windowHandler->MsgLow = WM_APP + 100;
>>>>>>
>>>>>> while(!Terminated)
>>>>>> messagePump();
>>>>>>
>>>>>> delete windowHandler;
>>>>>> }
>>>>>>
>>>>>> sometimes we get "Test exception" exception. We have up to 32
>>>>>> THttpConnection and 32 THttpCli descendents in this thread. When I
>>>>>> raised WHG_MAX to 800, the exception disappears. Francois, could
>>>>>> you raise the constant?
>>>>>
>>>>> This is probably because you post custom messages do you?
>>>>
>>>> Yes but they are starting from WM_USER and there are only 4 of them
>>>> in this thread. According to help, WM_USER starts from 0x0800 and
>>>> there should be enough room until WM_APP+100.
>>>>
>>>> Best Regards,
>>>>
>>>> SZ
>>> --
>>> 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
Re: [twsocket] Possible bug and solution in TWndControl
Fastream Technologies wrote:
> Yes these are all what I thought for a week time! I call GetMessage,
> then check for known/my messages. If none of them, call
> dispatchmessage and all works fine except the problem which goes away
> if we set the WHG_MAX to 800 instead of 100! Now there is no such
> exception thrown--tested with millions of connections.
Ahh, I missed that you use WM_APP + 100, that's a range I would not
use for window messages but something in the higher range of WM_USER
instead.
It's strange anyway that increasing the maximum number of messages made
the error went away since that shouldn't change the base number and range.
However here is a quick text-search in my component folder
VirtualTreeview:
WM_CHANGESTATE = WM_APP + 32;
VShellTools:
WM_NEWINPUT = WM_APP + 111;
WM_SHELLNOTIFY = WM_APP + 51; // Change in the Shell occured
WM_REMOVEBUTTON = WM_APP + 8; // VirtualShellToolbar
WM_CHANGENOTIFY_CUSTOM = WM_APP + 9;
WM_UPDATESCROLLBAR = WM_APP + 10;
WM_VETBASE = WM_APP + 100
and more..
So be carefull and find the sender!!
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
>
> Francois, will you?
>
> Best Regards,
>
> SZ
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Monday, February 05, 2007 1:50 PM
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
>
>>>> This is probably because you post custom messages do you?
>>>
>>> Yes but they are starting from WM_USER and there are only 4 of them
>>> in this thread. According to help, WM_USER starts from 0x0800 and
>>> there should be enough room until WM_APP+100.
>>
>> But there must somebody send messages in that range.
>>
>> At first check whether you send any message to the hidden component
>> window that has not been registered thru a call to
>> WndHandler.AllocateMsgHandler().
>>
>> Also, you can (should) use your own message pump in a thread, that
>> checks the HWND.
>>
>> if msg.hwnd = 0 then { Thread message }
>> begin
>> Any message that was posted to this thread goes here.
>> In this case you may even PostThreadMessages with message numbers
>> in the range of ICS messages.
>> end
>> else
>> Not a thread message, receiver is a window
>>
>> ---
>> Arno Garrels [TeamICS]
>> http://www.overbyte.be/eng/overbyte/teamics.html
>>
>>
>>
>>
>>
>> Fastream Technologies wrote:
>>> Hello Arno,
>>>
>>> - Original Message -
>>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>>> To: "ICS support mailing"
>>> Sent: Monday, February 05, 2007 1:24 PM
>>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>>
>>>
>>>> Fastream Technologies wrote:
>>>>> Hello,
>>>>>
>>>>> When I use the following thread code:
>>>>>
>>>>> void __fastcall ReverseProxyClientThread::Execute()
>>>>> {
>>>>> // Place thread code here
>>>>> FreeOnTerminate = true;
>>>>>
>>>>> ...
>>>>>
>>>>> TIcsWndHandler *windowHandler = new TIcsWndHandler();
>>>>> windowHandler->MsgLow = WM_APP + 100;
>>>>>
>>>>> while(!Terminated)
>>>>> messagePump();
>>>>>
>>>>> delete windowHandler;
>>>>> }
>>>>>
>>>>> sometimes we get "Test exception" exception. We have up to 32
>>>>> THttpConnection and 32 THttpCli descendents in this thread. When I
>>>>> raised WHG_MAX to 800, the exception disappears. Francois, could
>>>>> you raise the constant?
>>>>
>>>> This is probably because you post custom messages do you?
>>>
>>> Yes but they are starting from WM_USER and there are only 4 of them
>>> in this thread. According to help, WM_USER starts from 0x0800 and
>>> there should be enough room until WM_APP+100.
>>>
>>> Best Regards,
>>>
>>> SZ
>> --
>> 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] Possible bug and solution in TWndControl
Yes these are all what I thought for a week time! I call GetMessage, then
check for known/my messages. If none of them, call dispatchmessage and all
works fine except the problem which goes away if we set the WHG_MAX to 800
instead of 100! Now there is no such exception thrown--tested with millions
of connections.
Francois, will you?
Best Regards,
SZ
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Monday, February 05, 2007 1:50 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>> This is probably because you post custom messages do you?
>>
>> Yes but they are starting from WM_USER and there are only 4 of them
>> in this thread. According to help, WM_USER starts from 0x0800 and
>> there should be enough room until WM_APP+100.
>
> But there must somebody send messages in that range.
>
> At first check whether you send any message to the hidden component
> window that has not been registered thru a call to
> WndHandler.AllocateMsgHandler().
>
> Also, you can (should) use your own message pump in a thread, that
> checks the HWND.
>
> if msg.hwnd = 0 then { Thread message }
> begin
> Any message that was posted to this thread goes here.
> In this case you may even PostThreadMessages with message numbers
> in the range of ICS messages.
> end
> else
> Not a thread message, receiver is a window
>
> ---
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
>
>
>
>
>
> Fastream Technologies wrote:
>> Hello Arno,
>>
>> ----- Original Message -----
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Monday, February 05, 2007 1:24 PM
>> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>>
>>
>>> Fastream Technologies wrote:
>>>> Hello,
>>>>
>>>> When I use the following thread code:
>>>>
>>>> void __fastcall ReverseProxyClientThread::Execute()
>>>> {
>>>> // Place thread code here
>>>> FreeOnTerminate = true;
>>>>
>>>> ...
>>>>
>>>> TIcsWndHandler *windowHandler = new TIcsWndHandler();
>>>> windowHandler->MsgLow = WM_APP + 100;
>>>>
>>>> while(!Terminated)
>>>> messagePump();
>>>>
>>>> delete windowHandler;
>>>> }
>>>>
>>>> sometimes we get "Test exception" exception. We have up to 32
>>>> THttpConnection and 32 THttpCli descendents in this thread. When I
>>>> raised WHG_MAX to 800, the exception disappears. Francois, could you
>>>> raise the constant?
>>>
>>> This is probably because you post custom messages do you?
>>
>> Yes but they are starting from WM_USER and there are only 4 of them
>> in this thread. According to help, WM_USER starts from 0x0800 and
>> there should be enough room until WM_APP+100.
>>
>> Best Regards,
>>
>> SZ
> --
> 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] Possible bug and solution in TWndControl
>> This is probably because you post custom messages do you?
>
> Yes but they are starting from WM_USER and there are only 4 of them
> in this thread. According to help, WM_USER starts from 0x0800 and
> there should be enough room until WM_APP+100.
But there must somebody send messages in that range.
At first check whether you send any message to the hidden component
window that has not been registered thru a call to
WndHandler.AllocateMsgHandler().
Also, you can (should) use your own message pump in a thread, that
checks the HWND.
if msg.hwnd = 0 then { Thread message }
begin
Any message that was posted to this thread goes here.
In this case you may even PostThreadMessages with message numbers
in the range of ICS messages.
end
else
Not a thread message, receiver is a window
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
Fastream Technologies wrote:
> Hello Arno,
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Monday, February 05, 2007 1:24 PM
> Subject: Re: [twsocket] Possible bug and solution in TWndControl
>
>
>> Fastream Technologies wrote:
>>> Hello,
>>>
>>> When I use the following thread code:
>>>
>>> void __fastcall ReverseProxyClientThread::Execute()
>>> {
>>> // Place thread code here
>>> FreeOnTerminate = true;
>>>
>>> ...
>>>
>>> TIcsWndHandler *windowHandler = new TIcsWndHandler();
>>> windowHandler->MsgLow = WM_APP + 100;
>>>
>>> while(!Terminated)
>>> messagePump();
>>>
>>> delete windowHandler;
>>> }
>>>
>>> sometimes we get "Test exception" exception. We have up to 32
>>> THttpConnection and 32 THttpCli descendents in this thread. When I
>>> raised WHG_MAX to 800, the exception disappears. Francois, could you
>>> raise the constant?
>>
>> This is probably because you post custom messages do you?
>
> Yes but they are starting from WM_USER and there are only 4 of them
> in this thread. According to help, WM_USER starts from 0x0800 and
> there should be enough room until WM_APP+100.
>
> Best Regards,
>
> SZ
--
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] Possible bug and solution in TWndControl
Hello Arno,
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Monday, February 05, 2007 1:24 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl
> Fastream Technologies wrote:
>> Hello,
>>
>> When I use the following thread code:
>>
>> void __fastcall ReverseProxyClientThread::Execute()
>> {
>> // Place thread code here
>> FreeOnTerminate = true;
>>
>> ...
>>
>> TIcsWndHandler *windowHandler = new TIcsWndHandler();
>> windowHandler->MsgLow = WM_APP + 100;
>>
>> while(!Terminated)
>> messagePump();
>>
>> delete windowHandler;
>> }
>>
>> sometimes we get "Test exception" exception. We have up to 32
>> THttpConnection and 32 THttpCli descendents in this thread. When I
>> raised WHG_MAX to 800, the exception disappears. Francois, could you
>> raise the constant?
>
> This is probably because you post custom messages do you?
Yes but they are starting from WM_USER and there are only 4 of them in this
thread. According to help, WM_USER starts from 0x0800 and there should be
enough room until WM_APP+100.
Best Regards,
SZ
--
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] Possible bug and solution in TWndControl
Fastream Technologies wrote:
> Hello,
>
> When I use the following thread code:
>
> void __fastcall ReverseProxyClientThread::Execute()
> {
> // Place thread code here
> FreeOnTerminate = true;
>
> ...
>
> TIcsWndHandler *windowHandler = new TIcsWndHandler();
> windowHandler->MsgLow = WM_APP + 100;
>
> while(!Terminated)
> messagePump();
>
> delete windowHandler;
> }
>
> sometimes we get "Test exception" exception. We have up to 32
> THttpConnection and 32 THttpCli descendents in this thread. When I
> raised WHG_MAX to 800, the exception disappears. Francois, could you
> raise the constant?
This is probably because you post custom messages do you?
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
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] Possible bug and solution in TWndControl
Hello,
When I use the following thread code:
void __fastcall ReverseProxyClientThread::Execute()
{
// Place thread code here
FreeOnTerminate = true;
...
TIcsWndHandler *windowHandler = new TIcsWndHandler();
windowHandler->MsgLow = WM_APP + 100;
while(!Terminated)
messagePump();
delete windowHandler;
}
sometimes we get "Test exception" exception. We have up to 32
THttpConnection and 32 THttpCli descendents in this thread. When I raised
WHG_MAX to 800, the exception disappears. Francois, could you raise the
constant?
Best Regards,
SZ
--
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
