22

From MSDN, it seems that Application.DoEvents() is available in Windows.Forms. What would be the equivalent thing in WPF.

Shamim Hafiz - MSFT
  • 21,454
  • 43
  • 116
  • 176
  • Are you porting a legacy VB 6 application that uses `DoEvents`? Why do you think you need an equivalent to it? – Cody Gray - on strike Jul 21 '11 at 11:21
  • 4
    There is no equivalent. Stop doing that. No. –  Jul 21 '11 at 11:26
  • 2
    @Cody: No, I am not actually porting anything. I just needed the feature as described. – Shamim Hafiz - MSFT Jul 22 '11 at 05:54
  • 1
    FYI. Calling System.Windows.Forms.Application.DoEvents() works fine in WPF, and will run your dispatcher events, etc. You just need to add a reference to it. – BrainSlugs83 Dec 15 '13 at 00:20
  • 2
    @BrainSlugs83, WinForms' `DoEvents` won't pump Dispatcher operations (queued with `Dispatcher.BeginInvoke`). [More details](http://stackoverflow.com/q/21642381/1768303). – noseratio Feb 09 '14 at 05:27
  • Does this answer your question? [Where is the Application.DoEvents() in WPF?](https://stackoverflow.com/questions/4502037/where-is-the-application-doevents-in-wpf) – StayOnTarget Mar 03 '21 at 18:37

2 Answers2

23

While i agree with the Skeet you can find a WPF method like that on the documentation page of the DispatcherFrame

H.B.
  • 166,899
  • 29
  • 327
  • 400
  • 1
    Actually there are cases where is required, even if you are not performing a long running action on the UI thread. I have a user control where there is a long running action as a BackGroundWorker which also updates UI using dispatcher. However the control stops responding to Canvas.SetTop/Canvas.SetLeft while the backgroundworker is running, only using this code from MSDN can one get around it. – Malcolm McCaffery Jan 02 '13 at 00:10
  • @MalcolmMcCaffery: That sounds weird, i have never encountered anything like that, after all the whole point of the `BackgroundWorker` is to keep the UI responsive. Maybe you are issuing too many updates in a small amount of time so it chokes... – H.B. Jan 02 '13 at 06:38
  • Thanks for the link to the DispatcherFrame. – Mike Malter May 17 '13 at 20:29
22

You shouldn't be using it even in Windows Forms. Don't perform long-running tasks on the UI thread - use a background thread and use the Dispatcher to update the UI as required. Any use of Application.DoEvents is basically a code smell. I don't know whether there is an equivalent in WPF, but you should try to avoid it even if there is.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • I would not call it a code smell, because sometimes you need to manipulate UI objects in the computation (and dont do anything else than that) and in that case it is actually cleaner to call an equivalent of DoEvents(). – Tomas Grosup Jul 17 '12 at 06:50
  • 1
    @TomasGrosup: I'd say there are *very rarely* cases where it makes sense to use `Application.DoEvents`. It's pretty unusual for long-running work to be *purely* UI creation... and it would generally be cleaner to perform all other computation first, then just marshal to the UI thread for the purely UI part later. – Jon Skeet Jul 17 '12 at 08:13
  • Okay so say you update objects that are data bound, and all your OnPropertyChanged have fired. you then want to print a visual, surely it is not a code smell to call DoEvents() before printing the WPF visual to ensure that all the visuals have updated before you print. – DermFrench Jan 15 '13 at 16:52
  • Well what's initiating the printing, and why would that be executing before all the changes have become visible? And why would printing not re-render anyway? – Jon Skeet Jan 15 '13 at 17:04
  • I do all my logic in a background worker thread -- still brings the UI thread to a halt -- if I call Application.DoEvents() in a Timer, etc. the application runs flawless... until it eventually freezes because WPF doesn't like it... -- so, clearly, "Don't perform long-running tasks on the UI thread" isn't enough -- what else do we have to do to make WPF get off it's arse and handle its events? – BrainSlugs83 Dec 10 '13 at 07:28
  • 1
    @BrainSlugs83: Doing all the work in a background worker thread *really* shouldn't bring the UI to a halt. It sounds like there are other issues, which should be asked about in a separate question. `Application.DoEvents` may address the immediate symptoms, but it *isn't* the right answer. – Jon Skeet Dec 10 '13 at 08:23
  • 1
    I agree it isn't the *right* answer -- but unless we're all making the same mistakes (as this problem seems to be very common), neither is doing all your work in a background worker thread. :-/ -- thanks @JonSkeet, I will consider opening a new question. – BrainSlugs83 Dec 10 '13 at 23:20
  • @BrainSlugs83: I don't think it *is* very common, in terms of the UI locking up when you don't have any long-running tasks in it. I think it's more likely that you either *do* have a long-running task in the UI thread without realizing it, or you're doing something is theoretically short-lived, but needs to acquire a lock which is actually held by a long-running task elsewhere, which is just as bad. – Jon Skeet Dec 11 '13 at 06:46
  • Well, it seems to be asked commonly enough. Perhaps you're right. But, I ended up figuring out my scenario -- *I* was definitely not running code on the UI thread; my project was an Office Add-in though -- and when I invoked callbacks against the VSTO object model from background threads (no Dispatcher.Invoke, etc. it was definitely code running on the background thread), it turned out Word was somehow doing work on the main thread. I solved the issue by creating a separate thread to instantiate and show my dialog from, as shown here: http://stackoverflow.com/a/20534223/398630 – BrainSlugs83 Dec 15 '13 at 00:37