Hello,
I just 'fixed' a VERY strange V6 component behavior in a multi-threaded
server application that drove me nuts over the last hours >8-|
V6 worked great, however I simply forgot that messages in the range
of WM_USER up to WM_USER + IcsWndControl.WH_MAX_MSG
are now reserved for use with the TIcsWndHandler(s). So common,
custom messages sent to the same thread need to be defined above
that range!
Arno Garrels [TeamICS]

This make me thinking we could define the messages using the highest number
first and then going low. This would eliminate most clashes as many
applications start from WM_USER and goes up. Easy change to do.

I do agree. I already use v6 (old beta) but had no problem with the user
messages, using the latest beta without your proposal would break my app.

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Tuesday, June 20, 2006 8:12 PM
Subject: Re: [twsocket] About custom messages in V6

This make me thinking we could define the messages using the highest
number
first and then going low. This would eliminate most clashes as many
applications start from WM_USER and goes up. Easy change to do.

So the question is: what is the best highest number to use ?
Borland is already using messages starting from $B000 and $BC00 (See
Controls.pas).

Francois PIETTE wrote:
So the question is: what is the best highest number to use ?

Should they be in the WM_USER or WM_APP range?

Borland is already using messages starting from $B000 and $BC00 (See
Controls.pas).

Both $B000 and $BC00 are in the WM_APP range.

BTW: I also found CM__BASE in AxCtrls.pas, Ctl.pas and Activex.pas
starting at $2000.

0 through WM_USER-1 Messages reserved for use by the system.
WM_USER through 0x7FFF Integer messages for use by private window classes.
WM_APP through 0xBFFF Messages available for use by applications.
0xC000 through 0xFFFF String messages for use by applications.
Greater than 0xFFFF Reserved by the system for future use.

Arno Garrels [TeamICS]

Reading MSDN about WM_APP and WM_USER, I think WM_USER through 0x7FFF is the
correct range to use sin ce those messages are sent to the "private" hidden
window created by TWndControl. The only possible colision is with developper
own defined messages which are not allocated dynamically.

So we could make TWndControl start form WM_APP - 1 and going down.

Another possibility is to use RegisterWindowMessage. This would be slower
but a definitive solution. It may also solve the problem we talked not long
ago about recreating the messages for another thread. RegisterWindowMessage
would always give the same message number with the same string supplyed. We
could manage to create the strings from component name or something like
that. Just an idea

Francois PIETTE wrote:
TWndCntrol could also have a property (maybe just public to avoid
making it visible in the I which would confuse most basic users) to
select the starting message number, another to select up/down for
next message number and finally a last one for the maximum number of
messages (actually it is a constant equal to 100) handled by a single
window.

Great idea!

TWndCntrol could also have a property (maybe just public to avoid making it
visible in the I which would confuse most basic users) to select the
starting message number, another to select up/down for next message number
and finally a last one for the maximum number of messages (actually it is a
constant equal to 100) handled by a single window.

Francois PIETTE wrote:
So we could make TWndControl start form WM_APP - 1 and going down.

Going down is not convincing me, I would prefer a constant start number.
1024 through 32767 is a wide range, I think it's K to reserve 1000 or
2000 or even more numbers below WM_APP - 1, so that the component can
handle 'out of messages errors'. Beside that it's probably the best
solution, though I do not know how much slower RegisterWindowMessage
would be. There should be also a clear hint in the comments that messages
x through y are reserved for use with ICS (for fools like me).

Another possibility is to use RegisterWindowMessage. This would be
slower but a definitive solution. It may also solve the problem we
talked not long ago about recreating the messages for another thread.
RegisterWindowMessage would always give the same message number with
the same string supplyed. We could manage to create the strings from
component name or something like that. Just an idea

Hello Arno,

Just an idea. Wy not making it a startng property ? Then it is
evenutally user definable.

Rgds, Wilfried [TeamICS]

http://www.mestdagh.biz

Wednesday, June 21, 2006, 20:53, Arno Garrels wrote:

Francois PIETTE wrote:
>So we could make TWndControl start form WM_APP - 1 and going down.

Going down is not convincing me, I would prefer a constant start number.
1024 through 32767 is a wide range, I think it's K to reserve 1000 or
2000 or even more numbers below WM_APP - 1, so that the component can
handle 'out of messages errors'. Beside that it's probably the best
solution, though I do not know how much slower RegisterWindowMessage
would be. There should be also a clear hint in the comments that messages
x through y are reserved for use with ICS (for fools like me).

>Another possibility is to use RegisterWindowMessage. This would be
>slower but a definitive solution. It may also solve the problem we
>talked not long ago about recreating the messages for another thread.
>RegisterWindowMessage would always give the same message number with
>the same string supplyed. We could manage to create the strings from
>component name or something like that. Just an idea
>
>--
>francois.piette (AT) overbyte (DOT) be
>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, June 21, 2006 9:58 AM
>Subject: Re: [twsocket] About custom messages in V6
>
>
Francois PIETTE wrote:
So the question is: what is the best highest number to use ?

Should they be in the WM_USER or WM_APP range?

Borland is already using messages starting from $B000 and $BC00 (See
Controls.pas).

Both $B000 and $BC00 are in the WM_APP range.

BTW: I also found CM__BASE in AxCtrls.pas, Ctl.pas and
Activex.pas starting at $2000.

0 through WM_USER-1 Messages reserved for use by the system.
WM_USER through 0x7FFF Integer messages for use by private window
classes.
WM_APP through 0xBFFF Messages available for use by applications.
0xC000 through 0xFFFF String messages for use by applications.
Greater than 0xFFFF Reserved by the system for future use.

Arno Garrels [TeamICS]

--
francois.piette (AT) overbyte (DOT) be
http://www.overbyte.be

Message
From: "Frans van Daalen" <ics (AT) hedaal (DOT) nl>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Tuesday, June 20, 2006 8:38 PM
Subject: Re: [twsocket] About custom messages in V6

I do agree. I already use v6 (old beta) but had no problem with the
user messages, using the latest beta without your proposal would
break my app.

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Tuesday, June 20, 2006 8:12 PM
Subject: Re: [twsocket] About custom messages in V6

This make me thinking we could define the messages using the
highest number
first and then going low. This would eliminate most clashes as
many applications start from WM_USER and goes up. Easy change to
do.

--
Contribute to the SSL Effort. Visit
--
francois.piette (AT) overbyte (DOT) be
http://www.overbyte.be

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: <twsocket (AT) elists (DOT) org>
Sent: Tuesday, June 20, 2006 6:31 PM
Subject: [twsocket] About custom messages in V6

Hello,

I just 'fixed' a VERY strange V6 component behavior in a multi-
threaded server application that drove me nuts over the last
hours
8-|

V6 worked great, however I simply forgot that messages in the
range of WM_USER up to WM_USER +
IcsWndControl.WH_MAX_MSG
are now reserved for use with the TIcsWndHandler(s). So common,
custom messages sent to the same thread need to be defined above
that range!

Arno Garrels [TeamICS]