tags:

views:

602

answers:

5

I am a bit confused about the difference between events and messages in mfc. Are they the same?

+6  A: 

If we're talking about pure Win32, then these are different things:

An event is a kernel synchronization object kind of like a binary mutex. It can have two states: signalled and not signalled. It is used to synchronize threads, where a thread acquires it (using WaitForSingleObject or its cousins) and releases it through the SetEvent API.

A message is used by the window manager in user32 to notify windows of certain events, there are a lot of different messages for various purposes: Window management, painting, user input, ...

__grover
+2  A: 

Messages are for communication between windows. Events are for synchronization between threads.

Assaf Lavie
A: 

A bit more detail might be useful.

Events first.

So, you have your program running. You then create an event - the function call to use is CreateEvent(). That event has two states; signalled and non-signalled. (You choose the state it starts in). You can now wait on that event - which is to say, you can for example give that event to an operating system function call and then wait on that event. When the operating system is done, it will change the state of the event to signalled and your Wait() function call will return.

Now, if you've only one thread, this isn't much use - you could just call the operating system function and wait for it to return. But if you have multiple threads and you want to communicate between them - well, you can't make function calls to other threads. What you do instead is communicate with the other thread, tell it to do something and give it the event, and then Wait() until it's done.

Now, messages.

A program can have what's called a "message loop", which is a thread which blocks, reading the programs message queue. You can send a message to a thread (or window) and it will automatically be read by that thread. So one use is if you have a number of threads is to issue a termination message - it's time to quit. Another is to let the thread know you want it to do something - and a message can take two integer values as data, so you can pass over the handle to an event, too, so the thread can signal you when its done. (Or you could have it send you a message when its done; it all depends on how you want to organize your code - event based or message based).

Blank Xavier
Erm...why the -1 vote?
Blank Xavier
+2  A: 

Since you specifically ask about MFC, I assume you mean the event handlers and message handlers that you can define in the properties windows of a MFC class.

Under "events" you can define:

  • Handlers for WM_COMMAND windows messages.
  • MFC ON_UPDATE_COMMAND_UI handlers.
  • Handlers for child windows notification messages like ON_BN_CLICKED for handling of a button click in a dialog.

Under "messages" you can define message handlers for other Windows messages.

See also some explanation in msdn

In Win32 terms, both the events handlers and and message handlers, are in fact message handlers.

The other answers explain the difference between Windows events (unrelated to the MFC "events" described above), and Windows messages (correspond to both "events" and "messages" described above).

I you think that this is a bit confusing, I completely agree...

Dani van der Meer
A: 

Dani is correct: in the MFC world, an "event" is associated with a control, and passed via a WM_COMMAND message. "Message" is a broader term that encompasses all windows messages. See the msdn docs for something like BN_CLICKED for an example.

This is a regrettable overloading of the term "event", which is rather confusing. It is nothing to do with events in the wider Win32 world, which are kernel synchronization objects.

Bob Moore