Hello,
When I use the following thread code:
void __fastcall ()
{
// Place thread code here
FTerminate = 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

Fastream Technologies wrote:
Hello,

When I use the following thread code:

void __fastcall ()
{
// Place thread code here
FTerminate = 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]

Hello Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 ()
>{
>// Place thread code here
>FTerminate = 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

>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]

Fastream Technologies wrote:
Hello Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 ()
{
// Place thread code here
FTerminate = 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

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 with millions
of connections.

Francois, will you?

Best Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

>
>
>
>
>
Fastream Technologies wrote:
>Hello Arno,
>>
>Message
>From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 ()
{
// Place thread code here
FTerminate = 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

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 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_SHELLNTIFY = WM_APP + 51; // Change in the Shell occured
WM_REMVEBUTTN = WM_APP + 8; // VirtualShellToolbar
WM_CHANGENTIFY_CUSTM = WM_APP + 9;
WM_UPDATESCRLLBAR = WM_APP + 10;
WM_VETBASE = WM_APP + 100

and more
So be carefull and find the sender!!

Arno Garrels [TeamICS]

Francois, will you?

Best Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]
>
>
>
>
>
>
>Fastream Technologies wrote:
Hello Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 ()
{
// Place thread code here
FTerminate = 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
>Visit our website at http://www.overbyte.be

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 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

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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_SHELLNTIFY = WM_APP + 51; // Change in the Shell occured
WM_REMVEBUTTN = WM_APP + 8; // VirtualShellToolbar
WM_CHANGENTIFY_CUSTM = WM_APP + 9;
WM_UPDATESCRLLBAR = WM_APP + 10;
WM_VETBASE = WM_APP + 100

and more
So be carefull and find the sender!!

Arno Garrels [TeamICS]

>
>
>
>
>>
>Francois, will you?
>>
>Best Regards,
>>
>SZ
>>
>Message
>From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

Fastream Technologies wrote:
Hello Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 ()
{
// Place thread code here
FTerminate = 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
Visit our website at http://www.overbyte.be

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
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]

Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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_SHELLNTIFY = WM_APP + 51; // Change in the Shell occured
>WM_REMVEBUTTN = WM_APP + 8; // VirtualShellToolbar
>WM_CHANGENTIFY_CUSTM = WM_APP + 9;
>WM_UPDATESCRLLBAR = WM_APP + 10;
>WM_VETBASE = WM_APP + 100
>
>and more
>So be carefull and find the sender!!
>
>
>Arno Garrels [TeamICS]
>
>
>
>
>

Francois, will you?

Best Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

Fastream Technologies wrote:
Hello Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 ()
{
// Place thread code here
FTerminate = 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
Visit our website at http://www.overbyte.be
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be

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

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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
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]

>
>
>
>
>Regards,
>>
>SZ
>>
>Message
>From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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_SHELLNTIFY = WM_APP + 51; // Change in the Shell occured
WM_REMVEBUTTN = WM_APP + 8; // VirtualShellToolbar
WM_CHANGENTIFY_CUSTM = WM_APP + 9;
WM_UPDATESCRLLBAR = WM_APP + 10;
WM_VETBASE = WM_APP + 100

and more
So be carefull and find the sender!!

Arno Garrels [TeamICS]

Francois, will you?

Best Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

Fastream Technologies wrote:
Hello Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 ()
{
// Place thread code here
FTerminate = 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
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be

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]

Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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
>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]
>
>
>
>
>
Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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_SHELLNTIFY = WM_APP + 51; // Change in the Shell occured
WM_REMVEBUTTN = WM_APP + 8; // VirtualShellToolbar
WM_CHANGENTIFY_CUSTM = WM_APP + 9;
WM_UPDATESCRLLBAR = WM_APP + 10;
WM_VETBASE = WM_APP + 100

and more
So be carefull and find the sender!!

Arno Garrels [TeamICS]

Francois, will you?

Best Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

Fastream Technologies wrote:
Hello Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 ()
{
// Place thread code here
FTerminate = 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
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be

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]

Bjrnar 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_CUSTM_MESSAGE =
RegisterWindowMessage("MY_CUSTM_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 Bjrnar

>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.

Despite all have been said, I still think that 100 messages/thread is low.
It should be at least 400-600.

Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

Bjrnar 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_CUSTM_MESSAGE =
RegisterWindowMessage("MY_CUSTM_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 Bjrnar
>
>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.

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]

Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

Bjrnar 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_CUSTM_MESSAGE =
>RegisterWindowMessage("MY_CUSTM_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 Bjrnar
>
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.

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

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]

--
Bjrnar 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_CUSTM_MESSAGE =
>RegisterWindowMessage("MY_CUSTM_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 Bjrnar
>>
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.

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 [0WH_MAX_MSG]
of TIcsWndControl I would play with the value and find
an optimal setting for my application. 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]

Best Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]


>Regards,
>
>SZ
>
>Message
>From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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]
>
>
>
>Bjrnar 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_CUSTM_MESSAGE =
RegisterWindowMessage("MY_CUSTM_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 Bjrnar

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
>Visit our website at http://www.overbyte.be

BTW, where is Francois?
I'm here but working on a big contract.
Sorry but free support is given after everything else is done.

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.

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.mestdagh.biz

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

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

Hello,

I traced the bug to here:

function (
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.FList := L;
DebugString(PChar('TIcsWndHandler.Create List = ' +
IntToHex(Integer(Result.FList), 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

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

Fastream Technologies wrote:
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

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz
>
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Wednesday, February 07, 2007 10:51 AM
Subject: Re: [twsocket] Possible bug and solution in TWndControl

Fastream Technologies wrote:
>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 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
>>
>Message
>From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be

Fastream Technologies wrote:

I did not understand what you propose to have a single wndhandler per
thread with messages starting from WM_APP + 100 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]


>
>And check for HWND = 0 if you process custom thread messages sent by
>PostThreadMessage() (just to be sure).

Already doing this.

>
>
>
Regards,

SZ

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be

Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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 (
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.FList := L;
DebugString(PChar('TIcsWndHandler.Create List = ' +
IntToHex(Integer(Result.FList), 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]

--

And check for HWND = 0 if you process custom thread messages sent by
PostThreadMessage() (just to be sure).
>>
>Already doing this.
>>

Regards,

SZ

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be

Fastream Technologies wrote:
Arno,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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 (
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.FList := L;
DebugString(PChar('TIcsWndHandler.Create List = ' +
IntToHex(Integer(Result.FList), 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]
>
>
>

And check for HWND = 0 if you process custom thread messages sent
by PostThreadMessage() (just to be sure).

Already doing this.

Regards,

SZ

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be

Hello,

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Wednesday, February 07, 2007 3:11 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl

Fastream Technologies wrote:
>Arno,
>>
>Message
>From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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

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

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Wednesday, February 07, 2007 3:11 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl

Fastream Technologies wrote:
>Arno,
>>
>Message
>From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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 (
>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.FList := L;
>DebugString(PChar('TIcsWndHandler.Create List = ' +
>IntToHex(Integer(Result.FList), 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]

And check for HWND = 0 if you process custom thread messages sent
by PostThreadMessage() (just to be sure).

Already doing this.

Regards,

SZ

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be

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
Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Wednesday, February 07, 2007 3:11 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl

Fastream Technologies wrote:
>Arno,
>>
>Message
>From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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 (
>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.FList := L;
>DebugString(PChar('TIcsWndHandler.Create List = ' +
>IntToHex(Integer(Result.FList), 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]

And check for HWND = 0 if you process custom thread messages sent
by PostThreadMessage() (just to be sure).

Already doing this.

Regards,

SZ

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be

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 D HELP!

Regards,

SZ

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Wednesday, February 07, 2007 3:11 PM
Subject: Re: [twsocket] Possible bug and solution in TWndControl

Fastream Technologies wrote:
>Arno,
>>
>Message
>From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) 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 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 (
>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.FList := L;
>DebugString(PChar('TIcsWndHandler.Create List = ' +
>IntToHex(Integer(Result.FList), 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]

And check for HWND = 0 if you process custom thread messages sent
by PostThreadMessage() (just to be sure).

Already doing this.

Regards,

SZ

Message
From: "Wilfried Mestdagh" <wilfried (AT) mestdagh (DOT) biz>
To: "ICS support mailing" <twsocket (AT) elists (DOT) 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.mestdagh.biz

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be

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