0

We all know that calling the Application.DoEvents() method causes the current thread to be suspended while all waiting window messages are processed. If a message causes an event to be triggered, then other areas of the application code may execute. This can cause the application to exhibit unexpected behaviors that are difficult to debug. Also it has been advised to perform long and heavy operations or computations that take a long time on a new thread, but it seems, it will be useful to create a method (or an extension one!) using a filter for released messages for GUI controls to be able to simulate Application.DoEvents() for any arbitrary of them only. (i.e. to have a method like: myControl.DoEvents())

Do you have any idea about creating such a method?

nawfal
  • 70,104
  • 56
  • 326
  • 368
Mehdi
  • 2,194
  • 2
  • 25
  • 39
  • 2
    It doesn't make sense to have such a method. DoEvents runs the message loop once. You have one message loop in an application. It is managed by the Application class. Be *very* careful with DoEvents if such details are not clear. More here: http://stackoverflow.com/questions/5181777/use-of-application-doevents/5183623#5183623 – Hans Passant Mar 31 '12 at 08:40
  • @HansPassant. Thanks-I've read it before. What about `Application.AddMessageFilter`? May it help? – Mehdi Mar 31 '12 at 08:45
  • Help *what*? You haven't at all explained what you are trying to accomplish and why Application.DoEvents() isn't good enough. – Hans Passant Mar 31 '12 at 08:48
  • Let me bring an example. I have a UserControl which needs to be refreshed many times. It does this task using the `Refresh` method. I used this control in an application that has a time consuming process. Now, how can I enforce my control to be refreshed during a long process? – Mehdi Mar 31 '12 at 08:53
  • 4
    The problem is no doubt the "time consuming process", whatever that might mean. You can't have code consume a lot of time *and* keep the UI updated at the same time. Exactly the scenario where DoEvents is going to get you into trouble. Threads were made to solve that problem. Consume the time on a BackgroundWorker. – Hans Passant Mar 31 '12 at 09:00
  • Thanks @HansPassant. I think implementing a new thread causes the application to be more complicated and hence hard to debug. I had written a software some years ago with more than 40 threads. It works very good, but maintaining such a big application with many threads is not easy at all, particularly, when a bug appears. So I'm looking for a way to do this with a single thread. – Mehdi Mar 31 '12 at 10:16
  • @Mimi: Hans is telling you to do the right thing; you can't keep this cake and eat it, too. If you do anything time-consuming on the UI thread, you will not be able to simultaneosly refresh the UI. The BackgroundWorker is designed exactly for this scenario, it's easy to use and hides threading details from you. So using it won't be like the 40-thread quandary you suffered with earlier. – Alan Mar 31 '12 at 13:28
  • @Alan: I accepted Mr. Passant's answer. He is all right and I give thanks to him again here. All I wrote was a try to explain why I was about to find an _encapsulated way_ out to avoid threads complexity and be able to treat with a time consuming process on the GUI thread. I already know what a BackgroundWorker provides is one of the most simple ways to use thread features. Nevertheless, I decided to check this idea out. That's it! – Mehdi Mar 31 '12 at 17:31
  • @Mimi: Of course, and I'm really sorry if my comment accidentally came off as offensive. I felt you were deliberately avoiding a perfectly applicable solution because of an only slightly related bad past experience, so I tried to help by giving a small nudge. That's it :) – Alan Mar 31 '12 at 19:40
  • I found a pretty encapsulated way [here](http://www.codeproject.com/Articles/37642/Avoiding-InvokeRequired/). – Mehdi Apr 03 '12 at 09:59

0 Answers0