问题描述:

I'm new to .NET and Windows, and I am trying to figure out how to integrate legacy code into my C# project. The guy owning the code said he only needs "a message pump" and "idle processing".

After some googling, it sounds that at least MFC, Windows Forms and Win32 all have their own message pumps? Is this true?

My C# code is a console application which I understand does not have any message pump at all. I thought those were just GUI things(?).

So, what do I need to do in my C# code to make his old code work when he says he needs a "message pump"?

The code I need to use have been used in a GUI application. Now I need to use it in a server instead and got a bit terrified about the need for a GUI message pump. My code is pure C# without any GUI stuff in it at all. Just some number crunching and I/O.

网友答案:

Let me start with a little background on messages and message pumps.

In Windows, GUI applications work by handling messages. For example, when you move the mouse Windows sends a WM_MOUSEMOVE message to the window under the mouse.

Windows posts a message to the "message queue" of the thread that the window belongs to and someone has to route this message to the specific window. That someone is the message pump.

Every Windows UI framework has a message pump, and the simplest message pump looks like this (this code example is in C++; you can use interop to write it in .NET):

MSG msg;
while(GetMessage(&msg, hwnd, 0, 0))
{
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

Every GUI program must have a message pump, but a command-line program can start a message pump just by running the code above. Obviously, since you don't have open windows, you will not get any messages from the OS. To insert a message into the queue, use PostThreadMessage.

网友答案:

To run a message pump in .NET, call Application.Run();. This is a blocking call that will only finish running if the program receives a quit message. (Usually, if the system is shutting down). It is typically used by programs that need to wait for a specific event. (And, of course, by regular GUI applications.)

You can then handle the Application.Idle event.

If you need to handle Windows messages, you can create a hidden form, override its WndProc method, and pass it to Application.Run.

You can do all of this even in a server process.

网友答案:

You're right. In Windows, message pumps are "GUI things" although they are used for much more than that (hotkey notification, etc.).

A process can have a message pump per thread. Usually these are created when you create your first window. Console applications don't have message pumps. You could get around this by creating a Windows Forms window and making it invisible.

When you call Application.Run, Windows Forms will start your message pump. You can pass it the HWND of that window and it'll probably know what to do with it. If you want to catch messages sent back, you can override the forms WndProc. This will only catch messages sent to that window though...

相关阅读:
Top