Windows message queues c

Each window has a function, called a window procedure, that the system calls whenever it has input for the window. The window procedure processes the input and returns control to the system. For more information about window procedures, see Window Procedures. If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding.

In this case, the system hides the window and replaces it with a ghost window that has the same Z order, location, size, and visual attributes. This allows the user to move it, resize it, or even close the application.

However, these are the only actions available because the application is actually not responding. When in the debugger mode, the system does not generate a ghost window. The system passes input to a window procedure in the form of a message. Messages are generated by both the system and applications. The system generates a message at each input event—for example, when the user types, moves the mouse, or clicks a control such as a scroll bar.

The system also generates messages in response to changes in the system brought about by an application, such as when an application changes the pool of system font resources or resizes one of its windows. An application can generate messages to direct its own windows to perform tasks or to communicate with windows in other applications. The system sends a message to a window procedure with a set of four parameters: a window handle, a message identifier, and two values called message parameters.

The window handle identifies the window for which the message is intended. The system uses it to determine which window procedure should receive the message.

A message identifier is a named constant that identifies the purpose of a message. When a window procedure receives a message, it uses a message identifier to determine how to process the message.

Message parameters specify data or the location of data used by a window procedure when processing a message. The meaning and value of the message parameters depend on the message.

A message parameter can contain an integer, packed bit flags, a pointer to a structure containing additional data, and so on. When a message does not use message parameters, they are typically set to NULL.

A window procedure must check the message identifier to determine how to interpret the message parameters. The system sends or posts a system-defined message when it communicates with an application.

It uses these messages to control the operations of applications and to provide input and other information for applications to process. An application can also send or post system-defined messages. Applications generally use these messages to control the operation of control windows created by using preregistered window classes.

Each system-defined message has a unique message identifier and a corresponding symbolic constant defined in the software development kit SDK header files that states the purpose of the message. Symbolic constants specify the category to which system-defined messages belong. The prefix of the constant identifies the type of window that can interpret and process the message. Following are the prefixes and their related message categories. General window messages cover a wide range of information and requests, including messages for mouse and keyboard input, menu and dialog box input, window creation and management, and Dynamic Data Exchange DDE.

An application can create messages to be used by its own windows or to communicate with windows in other processes. If an application creates its own messages, the window procedure that receives them must interpret the messages and provide appropriate processing. The system uses two methods to route messages to a window procedure: posting messages to a first-in, first-out queue called a message queue , a system-defined memory object that temporarily stores messages, and sending messages directly to a window procedure.

A messages that is posted to a message queue is called a queued message. Most other messages, which are sent directly to a window procedure, are called nonqueued messages. The system can display any number of windows at a time. To route mouse and keyboard input to the appropriate window, the system uses message queues. The system maintains a single system message queue and one thread-specific message queue for each GUI thread. To avoid the overhead of creating a message queue for non—GUI threads, all threads are created initially without a message queue.

The system creates a thread-specific message queue only when the thread makes its first call to one of the specific user functions; no GUI function calls result in the creation of a message queue.

Whenever the user moves the mouse, clicks the mouse buttons, or types on the keyboard, the device driver for the mouse or keyboard converts the input into messages and places them in the system message queue.

The system removes the messages, one at a time, from the system message queue, examines them to determine the destination window, and then posts them to the message queue of the thread that created the destination window. A thread's message queue receives all mouse and keyboard messages for the windows created by the thread. The thread removes messages from its queue and directs the system to send them to the appropriate window procedure for processing. This ensures that a window receives its input messages in the proper first in, first out FIFO sequence.

However, for simplicity purposes I have created both functions in the same application. Next, we saw how to enable Message Queues server on Windows A similar process will be used for enabling it on other Microsoft operating systems. We then created a private message queue and finally created a simple Windows Forms application in C to first write a message to this queue and then read the message from the queue.

The example was simple with both the loading and reading being done from the same screen. However, in a real-life scenario the two functions can be done from separate applications residing on different servers and running in different processes.

Hence, this is not only a way to process data in an offline mode but also connect applications across boundaries. Happy Coding! View All. Using Message Queues In C. Munib Butt Updated date Dec 14, We will see what message queues are, why they are important, how to enable standard message queues in Windows 10, and how to create a simple message queue application in C. These days we see many business scenarios where large amounts of data must be processed.

Once the feature is installed, you will see the above screen. Right click on Private Queues and select to create a new queue,. The private queue is now created. That's true, but since it isn't called from inside the thread, it just won't create a message queue for the thread you intended to send a message to.

This is a Good Thing tm , too, since your thread 'knows' what it needs and is guarded against client code from outside telling it what it should have, in this case a message queue. I hope this makes sense,. I've been using this idea just recently, and to make my message queue happen, i have had the following code. Sometimes the queue just won't appear!!!! Does anyone know why? It is getting very frustrating, and i can't release software with a unreliably created message queue!!!

Thanks for any helps or pointers That's what i'm already doing. If you have a look at my post, I already use PeekMessage as the condition of the while loop , and it is repeatedly called until it succeeds.

Yes, so, in otherwords, yep It DOES work sometimes Seemingly intermittant. Worse still, it seems to work more often if i am watching it!!

More solid thread synchronization. Since the thread won't have a message queue, until the first call to GetMessage , the PostThreadMessage API call fails -- once it succeeds, we know that the respective thread has stored the information passed via the lpThreadParm and the main thread is safe to continue.

As long as the amount of time spent before calling GetMessage is not too long, this should work fine. At least you won't have to Sleep an arbitrary amount of time. In addition, your code doesn't check for failure of the PostThreadMessage call, but simply relies on n seconds being enough time for the thread to have started and created it's message queue.

There is a potential problem with that, since it would make the entire application stop responding if a single thread hangs. I would rather specify a finite timeout value and if it's reached, call TerminateThread for those threads that haven't terminated already.

Re: More solid thread synchronization Prakash Nadar 3-Mar Its a good idea but i dont know wheather there is a "flaw" To you use messagequeue for syncronization according to me is a bad idea.

When thread is created, message queue is not created it is created when a message is read from the queue, fine but dont ya think now its consuming more memory.??? Instead a simple event will do the same with less memory consumption.

I feel that if the thread is a worker thread then this idea is not acceptable. But its a very good idea for ui thread. Re: More solid thread synchronization. The most important thing to note is: this is not meant to replace synchronization via kernel objects, but rather an alternative way of achieving a similar result. Consequently, the intention was not to present a one-size-fits-all solution. Although you are correct that memory usage will be higher when installing a message queue, it is generally not a real world problem to be concerned about.

I'm currently also developing software for mobile devices 8MB RAM, no virtual memory via swap files, several applications installed in RAM already where running out of memory is a very real problem that has to be dealt with.

For current desktop PC's allocation of a few extra KB is usually nothing to pull your hair about. It is extremely important to be very clear about the pros and cons of both approaches synchronization with kernel objects vs. The most obvious advantage of kernel object synchronization is, that they are very efficient, both with respect to memory footprint and execution time. However, using events, it is tiresome to control a specific thread: If you put a kernel object in signaled state, any thread waiting for this object is potentially eligable to continue execution.

These events can occur at any time while the program is running, in almost any order. How do you structure a program whose flow of execution cannot be predicted in advance?

To solve this problem, Windows uses a message-passing model. The operating system communicates with your application window by passing messages to it. A message is simply a numeric code that designates a particular event. For example, if the user presses the left mouse button, the window receives a message that has the following message code.

Some messages have data associated with them. To pass a message to a window, the operating system calls the window procedure registered for that window. And now you know what the window procedure is for. An application will receive thousands of messages while it runs. Consider that every keystroke and mouse-button click generates a message. Additionally, an application can have several windows, each with its own window procedure. How does the program receive all these messages and deliver them to the correct window procedure?

The application needs a loop to retrieve the messages and dispatch them to the correct windows. For each thread that creates a window, the operating system creates a queue for window messages. This queue holds messages for all the windows that are created on that thread. The queue itself is hidden from your program.