Calls to SendMessage api

[Abubakar]

Hi,

My application has a lot of threads which at some point call SendMessage api
passing it the handle of the gui window. The calls r a lot. My question is
that should I call the SendMessage api by protecting it in a critical
section, or the SendMessage api itself handles this kind of situation where
a lot of threads in the same process r calling it.

Regards,

-ab.

[David Wilkinson]

Abubakar wrote:

Hi,

My application has a lot of threads which at some point call SendMessage api
passing it the handle of the gui window. The calls r a lot. My question is
that should I call the SendMessage api by protecting it in a critical
section, or the SendMessage api itself handles this kind of situation where
a lot of threads in the same process r calling it.

Regards,

-ab.

ab:

The good thing about SendMessage() is that it does not return until the
action in the other thread is complete. So you do not have to worry
about thread safety.

The bad thing about SendMessage() is that it does not return until the
action in the other thread is complete. So you can block yourself if you
are not careful. Many people say you should never use SendMessage() for
inter-thread communication. I disagree, but you DO need to be careful.

David Wilkinson

[Abubakar]

Ok, can u tell me what does the following means:

"The system only does marshalling for system messages (those in the range 0
to (WM_USER-1)). To send other messages (those >= WM_USER) to another
process, you must do custom marshalling."

This is from msdn documentation. Here I dont understand the meaning of "you
must do custom marshalling". The messages that so many of my threads r
sending to the gui handle r all declared greater than WM_USER and I'm not
doing anything extra than just passing those messages to the sendmessage
api.

regards,

-ab.

"David Wilkinson" <no******@effis ols.comwrote in message
news:OX******** ******@TK2MSFTN GP05.phx.gbl...

Abubakar wrote:

>Hi,

My application has a lot of threads which at some point call SendMessage
api passing it the handle of the gui window. The calls r a lot. My
question is that should I call the SendMessage api by protecting it in a
critical section, or the SendMessage api itself handles this kind of
situation where a lot of threads in the same process r calling it.

Regards,

-ab.

ab:

The good thing about SendMessage() is that it does not return until the
action in the other thread is complete. So you do not have to worry about
thread safety.

The bad thing about SendMessage() is that it does not return until the
action in the other thread is complete. So you can block yourself if you
are not careful. Many people say you should never use SendMessage() for
inter-thread communication. I disagree, but you DO need to be careful.

David Wilkinson

[William DePalo [MVP VC++]]

"Abubakar" <em**********@y ahoo.comwrote in message
news:Of******** ******@TK2MSFTN GP05.phx.gbl...

Ok, can u tell me what does the following means:

"The system only does marshalling for system messages (those in the range
0 to (WM_USER-1)). To send other messages (those >= WM_USER) to another
process, you must do custom marshalling."

The issue has to do with pointers.

The "w" and "l" parameters of a message will be the same on the sending and
receiving sides. Sometimes, one of those parameters which is defined to be a
simple unsigned quantity is used to pass an address as in the case of
WM_SETTEXT.

Because applications do not share their address spaces, a pointer in one
application is meaningless to another. So if Windows didn't handle it as a
special case, you couldn't send a WM_SETTEXT message across a process
boundary.

What the documentation is (almost <g>) telling you here is when you send a
message with a pointer in one of the messages with a value less than
WM_USER, that windows will pass the data as well as modifying the pointer on
the receiving side so that the receiver can access it.

Of course, in order for Windows to do this it needs to know which parameters
are pointers in which messages. Those messages are roughly the ones which
were defined in Windows 3.1.

For your own message, or many of the common controls introduced after 16 bit
Windows, you need to marshal the data.

Regards,
Will

[Abubakar]

Thanks.

-ab.

"William DePalo [MVP VC++]" <wi***********@ mvps.orgwrote in message
news:eU******** ******@TK2MSFTN GP05.phx.gbl...

"Abubakar" <em**********@y ahoo.comwrote in message
news:Of******** ******@TK2MSFTN GP05.phx.gbl...

>Ok, can u tell me what does the following means:

"The system only does marshalling for system messages (those in the range
0 to (WM_USER-1)). To send other messages (those >= WM_USER) to another
process, you must do custom marshalling."

The issue has to do with pointers.

The "w" and "l" parameters of a message will be the same on the sending
and receiving sides. Sometimes, one of those parameters which is defined
to be a simple unsigned quantity is used to pass an address as in the case
of WM_SETTEXT.

Because applications do not share their address spaces, a pointer in one
application is meaningless to another. So if Windows didn't handle it as a
special case, you couldn't send a WM_SETTEXT message across a process
boundary.

What the documentation is (almost <g>) telling you here is when you send a
message with a pointer in one of the messages with a value less than
WM_USER, that windows will pass the data as well as modifying the pointer
on the receiving side so that the receiver can access it.

Of course, in order for Windows to do this it needs to know which
parameters are pointers in which messages. Those messages are roughly the
ones which were defined in Windows 3.1.

For your own message, or many of the common controls introduced after 16
bit Windows, you need to marshal the data.

Regards,
Will