The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Windows messaging system #2

OK, still a bit confused...

I have a window, and this window has a message loop. Together they form a single thread of execution. This is a bit peculiar to me. After every piece of code execution (WM_PAINT, WM_TIMER, WM_BUTTON etc.) does the returning function ultimately end up going back to the message loop and asking the main loop (OS) what the next message in the queue is? If this is the case, explain the following scenario...

WindowA calls the function ::SendMessage(WindowB, ...). The processing of WindowB requires additional information, which it gets via a call to ::SendMessage(WindowA, ...). So how does WindowA receive this message and call further functions considering that it was in the middle of processing the original message? My guess is that SendMessage is a rentrant function, and releases execution at that point, continues as per usual, and then returns to the same point later on.

Ideas...?


(P.S. And if I am right, can anyone please elaborate on how to build such reentrant functions).
ThreadMan
Saturday, October 30, 2004
 
 
You are taking me back in time with this question, so I hope I still remember correctly. I believe that

SendMessage - Bypasses the message queue and goes directly to that window that is supposed  to receive the message

PostMessage - Puts a message on the queue that will eventually get processed.

I hope this helps.
Roger Jack Send private email
Saturday, October 30, 2004
 
 
Maybe I'm all wrong,

but I see it as recursion. Instead of calling yourself
directly, Windows calls your WndProc while original
call sits there and waits.

Try using static variable and increment it at start of WndProc.

LRESULT CALLBACK WndProc (...)
{
  static int counter = 0;
  int        savedCnt;

  counter++;

...
  savedCnt = counter;
  result = SendMessage (...);
  if (savedCnt != counter)
      MessageBox (...);
}
VPC
Saturday, October 30, 2004
 
 
"If you want truly to understand something, try to change it."
Alex Send private email
Saturday, October 30, 2004
 
 
Basically if you read the documentation for SendMessage it will make sense to you.

1. WindowA and WindowB are created by the same thread.
2. WindowA sends a message to WindowB.
3. The SendMessage function automatically executes WindowB's WndProc to process the sent message.
4. WindowB's WndProc processes the message and returns.
5. Execution begins again at the statement after the SendMessage in WindowA.

Execution in the same thread is linear.  The instruction pointer is simply changed to point at the appropriate instruction.

Saturday, October 30, 2004
 
 
It seems you have an extra step in your problem...

1. WindowA and WindowB are created by the same thread.
2. WindowA sends a message to WindowB.
3. The SendMessage function automatically executes WindowB's WndProc to process the sent message.
4. WindowB's WndProc encounters the SendMessage to WindowA.
5. The SendMessage function automatically executes WindowA's WndProc to process the sent message.
6. WindowA's WndProc returns.
7. Execution begins again at the statement after the SendMessage in WindowB.
8. WindowB's WndProc returns.
9. Execution begins again at the state after the SendMessage in WindowA.

Same concept.  I guess you could think of it as recursive.

Saturday, October 30, 2004
 
 
I found this one of the most confusing aspects of Windows development at first. Coming from a real time embedded background I had a strong idea of what a thread was. Learning that one message handler for Window A could be "interrupted" by another message handler for Window A was a shock. Until I grasped the whole message loop fully.

Still seems weird sometimes...
sgf
Sunday, October 31, 2004
 
 
Wait till you want to understand COM 'apartments'.

  Flava Flav!
Flava Flav
Monday, November 01, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz