0

I have a multiple dialog MFC client app that i am working on. This client can receive a lot of messaging (>10Hz) to the main dialog, which often performs some small function, then forwards that message onto the another dialog for processing.
In my specific case, the main dialog receives messages relating to a vehicle location, updates a couple fields on that GUI, then passes it on vi a PostMessage to a window that displays all the vehicle information.

So basically, my question is this: what is the difference b/w posting the message, or just calling the dialog.update (which is a function i created)?

Jason
  • 2,147
  • 6
  • 32
  • 40

2 Answers2

0

Well, since we don't know what your dialog.update() does, how are we to know what the difference is?

If you are doing another PostMessage, I'm not sure what the point of that is. Your program has to wait for another iteration of the message loop to retrieve your newly posted message and possibly another message could be received before that one is posted. Instead of PostMessage, you could use SendMessage which will send the message straight to the WndProc without having to iterate the message loop for another message.

I am thinking that if you are multi-threaded, then sending or posting messages will be a little more thread safe since Windows should switch contexts automatically. If you are single threaded, then it probably shouldn't matter.

Joseph Willcoxson
  • 5,853
  • 1
  • 15
  • 29
  • Yes the program is multithreaded. Let's say the second windproc calls the same function that the dialog.update() does. Someone told me that the Post Message sends it out and doesn't wait for the update to complete, but if i do the dialog.update(), then my code will not continue until the update completes. Is that the case? – Jason Jul 18 '12 at 12:07
  • Yes, basically. All a PostMessge does is put a message in the message queue for the thread that owns the window and then returns. The thread that owns the window has to then pump messages until it gets to the message that you posted to it. However, if you do a SendMessage, the message will go immediately to the WndProc of the window and won't return until the message is processed. – Joseph Willcoxson Jul 18 '12 at 14:28
  • So in the 3 options: 1) Post Message, 2) Send Message, and 3) Dialog.update(), this is what i have: 1) will post immediately and return. The receiver of the message will get around to processing the message 2) will post immediately, but waits for reciever to complete before returning. 3) same as no. 2. am i reading that right? – Jason Jul 18 '12 at 18:56
  • Yes, but in "2)" I'd use the word "sent" and not "post". If your windows are in different threads, than option 2 is probably a better option than 3. – Joseph Willcoxson Jul 18 '12 at 21:53
0

I believe your application is multithreaded, and one of the thread is receivng the data, and is different than GUI thread. You should use PostMessage only from other thread to this dialog, and not SendMessage or direct call.

If you are receiving too many messages, you should buffer them - either by count (say 5000), or by some timeout. You may keep the messages into vector, list or any other collection you like. Later, when sending, post the address of this collection as WPARAM (or LPARAM) to the dialog. Dialog will get it, in a single bunch and would process it. This approach may not be correct as I am not aware about other design perspetives of your application.

You would need to trial-and-error approach, see where you get the actual performance and stability benefits.

Ajay
  • 18,086
  • 12
  • 59
  • 105