By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,345 Members | 2,404 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,345 IT Pros & Developers. It's quick & easy.

SendMessage API question

P: n/a
Hi,
in my application, different threads send notifications to GUI thread
through sendmessage api. They have special integer numbers inside the wParam
arg of sendmessage which the gui thread uses to display messages in the
textboxes etc. My question is that in case the threads send messages very
fast (which does NOT always happen in my app), faster than the gui thread is
processing them, are the messages qued automatically (btw the gui part when
starts processing on a message, it calls entercriticalsection and when its
done calls leavecriticalsection. I added these because I thought they would
be needed, but gui thread is just one thats going to work on the message
received and thats y I'm not sure I will need this critical section api
calls here or not. Need some comments on this approach also.)?
Example (writing here what I think the way things work):
thread 1 sends message1
thread 2 sends message2 (qued)
thread1 send message 3 (qued)
gui thread processes message1
gui thread processes msg2
thread2 sends message4
gui thread processes message3
gui thread processes message4

everything done nicely, I had to do no queing my self.

Is that what happens?

Regards,

Abubakar.
Mar 15 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Hi,
in my application, different threads send notifications to GUI thread
through sendmessage api. They have special integer numbers inside the
wParam
arg of sendmessage which the gui thread uses to display messages in the
textboxes etc. My question is that in case the threads send messages very
fast (which does NOT always happen in my app), faster than the gui thread
is
processing them, are the messages qued automatically
Yes. From MSDN:
Windows 2000/XP: There is a limit of 10,000 posted messages per message
queue. This limit should be sufficiently large. If your application exceeds
the limit, it should be redesigned to avoid consuming so many system
resources. To adjust this limit, modify the following registry key ...
Note that SendMEssage blocks the sender until the message is handled, and
Post message doesn't
starts processing on a message, it calls entercriticalsection and when its
done calls leavecriticalsection. I added these because I thought they
would
be needed, but gui thread is just one thats going to work on the message
received and thats y I'm not sure I will need this critical section api
You don't need the critical sections, as only 1 message is handled at a time
by default.
calls here or not. Need some comments on this approach also.)?
Example (writing here what I think the way things work):
thread 1 sends message1
thread 2 sends message2 (qued)
thread1 send message 3 (qued)
gui thread processes message1
gui thread processes msg2
thread2 sends message4
gui thread processes message3
gui thread processes message4


That is what should happen. You should keep your message handlers very small
..i.e. no extensive processing inside the message handlers.

--

Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"
Mar 15 '06 #2

P: n/a
Thanks.

Abubakar.

"Bruno van Dooren" <br**********************@hotmail.com> wrote in message
news:#q**************@TK2MSFTNGP10.phx.gbl...
Hi,
in my application, different threads send notifications to GUI thread
through sendmessage api. They have special integer numbers inside the
wParam
arg of sendmessage which the gui thread uses to display messages in the
textboxes etc. My question is that in case the threads send messages very fast (which does NOT always happen in my app), faster than the gui thread is
processing them, are the messages qued automatically
Yes. From MSDN:
Windows 2000/XP: There is a limit of 10,000 posted messages per message
queue. This limit should be sufficiently large. If your application

exceeds the limit, it should be redesigned to avoid consuming so many system
resources. To adjust this limit, modify the following registry key ...
Note that SendMEssage blocks the sender until the message is handled, and
Post message doesn't
starts processing on a message, it calls entercriticalsection and when its done calls leavecriticalsection. I added these because I thought they
would
be needed, but gui thread is just one thats going to work on the message
received and thats y I'm not sure I will need this critical section api
You don't need the critical sections, as only 1 message is handled at a

time by default.
calls here or not. Need some comments on this approach also.)?
Example (writing here what I think the way things work):
thread 1 sends message1
thread 2 sends message2 (qued)
thread1 send message 3 (qued)
gui thread processes message1
gui thread processes msg2
thread2 sends message4
gui thread processes message3
gui thread processes message4
That is what should happen. You should keep your message handlers very

small .i.e. no extensive processing inside the message handlers.

--

Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"

Mar 15 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.