Is there an alternative to using a background worker in WPF?

Question

I start with WPF, in my application I need to perform a number of initialization steps, it will take 10-15 seconds, during which my user interface stops responding.

I used the background of the worker yesterday, but he did not refresh my window; in fact, it was frozen. Not sure, but maybe this didn't work because this control is for Windows Forms only.

UPDATE:

If there are not too many problems, can you post me an example to use an alternative? For my case, the program will get some values ​​from the database in blucle.

Answer 1

Dispatcher The dispatcher maintains a priority work item queue for a specific thread. This can help you upgrade your user interface. If you have a lot of user interface initialization, even this will not help you.

Dispatcher is not always an alternative to BackgroundWorker. The best practice is to choose the one that suits your requirements best. For example, if you want something to run without a queue, BackgroundWorker is the solution. On the other hand, if priority is not an issue, Dispatcher is an alternative. For example, the dispatcher uses Spell checkers and syntax highlighting functions.

WPF Stream Model

All WPF applications start with two important threads: one for rendering and one for managing the user interface. Thread rendering is a hidden thread that runs in the background, so the only thread you usually access is the user interface thread. WPF requires that most of its objects are bound to a user interface thread. This is called thread affinity, that is, you can only use the WPF object in the stream on which it was created. Using it on other threads will throw an exception to execute. Please note that the WPF streaming model works well with the Win32® APIs. This means that WPF can host or be hosted by any HWND interface (Windows Forms, Visual Basic®, MFC, or even Win32).

The affinity of the thread is handled by the class manager, a priority message loop for WPF applications. As a rule, your WPF projects have one Dispatcher object (and, therefore, one UI) through which all work with the user interface is carried out.

NOTE:

The main difference between the Dispatcher method and other threads is that the dispatcher is actually not multithreaded. The dispatcher controls the controls that need a single thread to work properly; BeginInvoke method for event queue manager for later execution (depending on priority, etc.), but still in the same topic.

See this for more details.

Answer 2

You can also queue items with a thread pool and run such tasks, but be careful if your tasks need to update the user interface when they are complete, you will need to transfer the data back to the user interface thread.

Answer 3

You can use asynchronous delegates.

http://msdn.microsoft.com/en-us/library/ms228963.aspx

Just make sure you use any UI related updates:

Dispatcher.CheckAccess() 

Here is a simple example:

 private void HandleUIButtons() { if (!btnSplit.Dispatcher.CheckAccess()) { //if here - we are on a different non-UI thread btnSplit.Dispatcher.BeginInvoke(new Action(HandleUIButtons)); } else { btnSplit.IsEnabled = true; //this is ultimately run on the UI-thread } } 

Taken from here:

http://blog.clauskonrad.net/2009/03/wpf-invokerequired-dispatchercheckacces.html