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 twsocket@elists.org
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
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 twsocket@elists.org 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
- Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org 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 twsocket@elists.org 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: 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 twsocket@elists.org 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
Arno,
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
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 twsocket@elists.org
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:
Arno,
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
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 twsocket@elists.org
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
Hello, - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org 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 twsocket@elists.org 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
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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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
--
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, 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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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
--
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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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
--
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
-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
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? 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
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 twsocket@elists.org 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
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 twsocket@elists.org 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 twsocket@elists.org 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: 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 twsocket@elists.org 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 twsocket@elists.org 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
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 twsocket@elists.org 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 twsocket@elists.org 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 twsocket@elists.org 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
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
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 twsocket@elists.org 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
[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
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
Re: [twsocket] Possible bug and solution in TWndControl
Hello Arno,
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
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
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 twsocket@elists.org
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
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 twsocket@elists.org
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 twsocket@elists.org
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
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 twsocket@elists.org
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 twsocket@elists.org
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
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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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:
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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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
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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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
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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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 twsocket@elists.org
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
