2

I'm converting a C++ application to C# and I've come across this single line of code in numerous places in the codebase:

Application->ProcessMessages()

I found this link: http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Forms_TApplication_ProcessMessages.html

Which says ProcessMessages() does the following:

Call ProcessMessages to permit the application to process messages that are currently in the message queue. ProcessMessages cycles the Windows message loop until it is empty, and then returns control to the application.

But what is a "message" and what is the "message queue"? How do messages get added? What sort of processing is done?

I can't seem to find any concrete explanations as to what this does, which is important because I don't know what would be the C# / .NET equivalent of this method call, or is it its functionality in some shape or way just baked into .NET and I don't need to do anything?

Tagged question with C# since I'm most curious about its .NET equivalent, but the real intent of the thread is simply to understand what this does as far as C++ is concerned.

sab669
  • 3,984
  • 8
  • 38
  • 75
  • 1
    Why don't you [learn](https://msdn.microsoft.com/en-us/library/windows/desktop/ms632586(v=vs.85).aspx) it yourself? Start from [here](https://msdn.microsoft.com/en-us/library/windows/desktop/ms644927(v=vs.85).aspx) if you want to jump right into messages. – Sinatr Jan 05 '16 at 13:59
  • 2
    It is the notorious "DoEvents". Every GUI library allows this, it should [never be used](http://stackoverflow.com/a/5183623/17034). – Hans Passant Jan 05 '16 at 14:05

2 Answers2

8

The .NET equivalent is Application.DoEvents().

The message pump is the Win32 messaging system that is actually the communication mechanism of Windows itself. If you move your mouse, click a button, etc. a message is sent. A party (your application, Windows itself, etc) capable handles it, and the next message is handled. The message pump keeps sending through message that are put in the queue.

Application.DoEvents() will give your synchronous code the chance to handle those events, but it is better to make your code asynchronous so the UI thread doesn't get blocked and the messages can be handled normally without delay.

Don't use Application.DoEvents() unless you really know what you are doing and know it can bring trouble.

Community
  • 1
  • 1
Patrick Hofman
  • 153,850
  • 22
  • 249
  • 325
  • Both asynchronous code and `Application.DoEvents()` have one critical issue in common, though - they allow for re-entrancy. Oh, all the leaky abstractions... :) – Luaan Jan 05 '16 at 14:05
  • `DoEvents()` is a workaround, but it can [cause problems](http://stackoverflow.com/q/5181777/1997232) on its own. Do not use it if you can. – Sinatr Jan 05 '16 at 14:05
  • Indeed. Thanks for emphasizing that @Sinatr. Usually it is an indicator of a bad design. – Patrick Hofman Jan 05 '16 at 14:06
  • Indeed a code using DoEvents usually is a bad piece of code. IF you need to do heavy work and update the interface, use another thread and update the interface asynchronously – Gusman Jan 05 '16 at 14:06
  • Thanks for the explanation and source links, appreciated! – sab669 Jan 05 '16 at 14:09
  • IMO = For single core, single thread systems, Application.DoEvents() is the only way. Not that important anymore but code really should know if it can spawn any threads at all. If not then fall through to Application.DoEvents() –  Jan 10 '22 at 15:07
3

ProcessMessage function allows the application, to process queued windows messages.

Windows work through messages, each event (mouse move, click, key press, redraw, etc) is a message sent to the window. All this process in .net is handled automatically so you don't have to worry on coding a WNDPROC for each window.

So, I believe you will have that line of code inside a loop of heavy work. For what? to leave time to the interface to refresh itself.

In .net you can use the Application.DoEvents() function as it will effectively call the ProcessMessages function. Source.

Patrick Hofman
  • 153,850
  • 22
  • 249
  • 325
Gusman
  • 14,905
  • 2
  • 34
  • 50