Where Is the Application.Doevents() in Wpf

Where is the Application.DoEvents() in WPF?

The old Application.DoEvents() method has been deprecated in WPF in favor of using a Dispatcher or a Background Worker Thread to do the processing as you have described. See the links for a couple of articles on how to use both objects.

If you absolutely must use Application.DoEvents(), then you could simply import the system.windows.forms.dll into your application and call the method. However, this really isn't recommended, since you're losing all the advantages that WPF provides.

What is equivalent to Application.DoEvents() in WPF applications

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.

How do I DoEvents in WPF?

VB.NET does support anonymous delegates, but only as single-statement functions. (Multi-statement anonymous functions and anonymous Subs have been added to VB10 in .NET 4)

To provide context, DoEvents was designed to allow a single-threaded environment to update the UI and process other Windows messages while work was being done. There should be no benefit to calling DoEvents (or, as you're doing here, doing so indirectly by executing a "null" function on the dispatcher) from another thread, as the UI thread should be updating by itself.

In the interest of answering your question, though, the easiest option would be something like this:

Application.Current.Dispatcher.Invoke(DispatcherPriority.Background, _
    New Action(Function() 7))

But, again, I can't see what this would actually accomplish.

If what you're looking for is simply how to execute code on the UI thread (like the Control.Invoke from Windows forms), then Dispatcher.Invoke (which is what you're using) is correct, you'll just have to translate your inline anonymous methods into discreet functions and pass those as delegates. There may be some that you can get away with leaving as anonymous. For example, if all you're doing is updating a progress bar, you could do:

Application.Current.Dispatcher.Invoke(DispatcherPriority.Background, _
    New Action(Function() progressBar.Value = 100))

This works because all assignments return the value that was stored in the left side of the assignment. You could not, however, just call a sub like this (the following won't compile unless SomeFunctionName returns a value):

Application.Current.Dispatcher.Invoke(DispatcherPriority.Background, _
    New Action(Function() SomeFunctionName(params)))

In other words, any of the anonymous delegates that are in the C# code that either:

• Are more than one statement
• Do not return a value (meaning it's just a single call to a method, not a function)

Then you'll have to create functions for those and pass delegates to those functions rather than inlining the code as you have in C#.

WPF DoEvents : how to implement it?

There is no difference between both solutions except the syntax. ThreadStart and Action are both delegates which have the same declaration and only a name is different:

public delegate void ThreadStart();
public delegate void Action();

You can also create your own delegate and use is in the same way e.g.:

public delegate void MyOwnAction();
...
Application.Current.Dispatcher.Invoke(
    DispatcherPriority.Background, new MyOwnAction(() => { }));

You can also use a specific method and not anonymous one:

private void Target()
{
    ...
}

Application.Current.Dispatcher.Invoke(
    DispatcherPriority.Background, new MyOwnAction(Target));

Alternative to Application.DoEvents() in wpf

Create a new Success event, fire it when you hit your success condition, and then put the code you need to execute on Success in an event handler for that event:

define the event:

public event Action Success;

Attach the handler:

kl.KeyDown += CheckPwd;
Success += DoSuccessStuff;

Fire the event:

void CheckPwd(object sender, KeyEventArgs e)
{
   //some code here
   if(...)
   {
       flag = true;
       Success = true;   
       kl.KeyDown -= CheckPwd;   
       if(Success != null) Success();
   }
   //...

Proper use of DoEvents() that compatible with WPF

Or maybe I shouldn't use this method anymore?

This.

Basically, the use of Application.DoEvents() is almost always an indication that you've got a long-running task which should be executed on a different thread, calling back to the UI thread where UI access is required.

Application.DoEvents() is basically a hack people use when they don't want to take the time to do things properly - at least in the vast majority of cases.

There are various ways of writing long-running tasks which interact with the UI, depending on which versions of the language/framework you're using, and what your long-running task consists of. Options to consider:

• Explicitly creating a new thread
• Explicitly using the thread pool
• Using BackgroundWorker
• Using the Task Parallel Library (TPL) - requires .NET 4+
• Using asynchronous APIs, which is much simpler as of .NET 4.5 / C# 5

Use of Application.DoEvents()

From my experience I would advise great caution with using DoEvents in .NET. I experienced some very strange results when using DoEvents in a TabControl containing DataGridViews. On the other hand, if all you're dealing with is a small form with a progress bar then it might be OK.

The bottom line is: if you are going to use DoEvents, then you need to test it thoroughly before deploying your application.

Is Application.DoEvents() just for WinForms?

Yes, it's really aimed at Windows Forms. However, in my view it should be avoided where possible.

It's usually used as a hack by developers who don't want to be bothered with putting long-running operations on a different thread... but that means they're introducing re-entrancy issues which can be very hard to track down, as well as still blocking the UI thread for some of the time (and if that includes something like a file operation, you can't really predict whether the operation will complete quickly enough to not have a user visible effect).

---

Related Topics