-5
While True
   Application.DoEvents()
   System.Threading.Thread.Sleep(500)
End While

If I run this I observe the expected behavior of my form processing user events every 500 ms. I understand from the documentation that the message queue is being processed with every call to DoEvents().

What I am not understanding is where this processing fits in the threading model of .NET. Is the event processing as a result of the call to DoEvents() necessarily happening on the UI thread? What about if DoEvents() is called from another thread besides the UI thread?

Steve M
  • 9,296
  • 11
  • 49
  • 98
  • 1
    http://stackoverflow.com/q/5181777/1070452 ...or the many others under "related" on the right – Ňɏssa Pøngjǣrdenlarp Jul 08 '14 at 23:48
  • I haven't read through all of them yet, but it I haven't found one yet that answers my question as to whether DoEvents() happens on the same Thread as it is called from. – Steve M Jul 08 '14 at 23:53
  • 2
    Of course it does. Beyond the standard mistake of fixing problems with DoEvents, sleeping for 500 msec is far too long and makes the UI very sluggish. – Hans Passant Jul 08 '14 at 23:56
  • @Hans it appears per the documentation link below that the processing will happen on the UI thread, not necessarily the thread it is called from. And this was a theoretical question, I'm not using this anywhere. – Steve M Jul 09 '14 at 00:09
  • That's nonsense. It runs on a worker thread as well, there just will be no events to do. – Hans Passant Jul 09 '14 at 00:41
  • @Hans Thanks, upon rereading it seems you are correct. – Steve M Jul 09 '14 at 01:06

1 Answers1

1

It enables the application to 'hear for' any events (like an Esc key, etc.) and take action for those interrupts.

So sometimes a long loop may freeze user interactivity with everything in the application and it may not be accessible. And other code internally which relies on events like MouseOver etc. may not be trapped.

This line will be like a safety valve for the loop, enabling it to slow down and check for events in between execution. This, however, does slow down the loop somewhat so it should be used every 'n' iterations in case of long loops.

hnk
  • 2,216
  • 1
  • 13
  • 18
  • Does it run on the same thread as it is called from? – Steve M Jul 08 '14 at 23:54
  • The documentation is not 100% clear but it would seem momentarily so. i.e. the same thread kicks of the message checking (processing events) but what happens then should depend on how the event-handler was written. Most standard ones should start a separate thread of their own. i.e. if the worker thread calls Application.DoEvents(), any events raised will be processed by the UI thread (msdn: http://msdn.microsoft.com/en-us/library/aa446540.aspx). So it would still depend on how the event handling works specifically. – hnk Jul 09 '14 at 00:01
  • So it seems the events are always processed on the UI thread, regardless of where it is called from. – Steve M Jul 09 '14 at 00:06
  • unless you've written some custom events, i.e. Usually events would relate to getting user interaction and so should be handled by the UI thread in any well designed application – hnk Jul 09 '14 at 00:08