There appears to be a lot of resources on showing the busy cursor.
But all the solutions I've managed to find relies on setting the cursor via the view model. (i.e, IsBusy property, disposable WaitCursor).
These methods work well when I know when my data binding/view models will be long-running.
But I don't know how to do this automatically for cases where the bottleneck is the actual WPF user control itself?
For example:
Loading a control is initially lag-free. But once a 3rd party control is used, the control exhibits a 500-ms lag every time it loads.
The binding itself is fast, hence, adding a waitcursor/IsBusy in the view model is useless because it wouldn't know when the control (or any of its logical/visual children) has finished rendering. Nor should it know, as the view model should not be affected by the view's implementation.
Is it possible for the application to automatically set the cursor to busy when one or more WPF controls is busy/slow?
You may need something like this,
var busytimer = new DispatcherTimer(
TimeSpan.FromSeconds(1),
DispatcherPriority.Normal,
delegate
{
Process application = null;
foreach (var process in Process.GetProcesses())
{
if (process.ProcessName == "Your process name")
{
application = process;
break;
}
}
if (!application.Responding)
{
this.Cursor = Cursors.Wait;
}
else
{
this.Cursor = Cursors.Arrow;
}
},
Application.Current.Dispatcher);
Is it possible for the application to automatically set the cursor to busy when one or more WPF controls is busy/slow?
Not really. If your UI thread is blocking, you won't be able to update the cursor until it becomes unblocked anyway, which defeats the purpose.
The binding itself is fast, hence, adding a waitcursor/IsBusy in the view model is useless because it wouldn't know when the control (or any of its logical/visual children) has finished rendering. Nor should it know, as the view model should not be affected by the view's implementation.
If you go with the IDisposable wait cursor solution, you could try scheduling the Dispose() call to occur after the next layout pass:
Dispatcher.CurrentDispatcher.BeginInvoke(
DispatcherPriority.Loaded,
new Action(() => waitCursor.Dispose()));
Related
I have a helper class I've written which can be used to run a long running task on my GUI. What it does is use styles to display a "working" animation and fades out the content so while the task is running, the user can see that something is in progress.
My problem is that when the long running task completes, it fades the content back in and hides the working animation - which is what it should do, but because I am using MVVM and primarily data binding for all my content display, the updates to the GUI components happen separately to the long running task. ie the data binding OnPropertyChanged("") events fire and then these are picked up by the GUI thread AFTER the long running task completes. But the problem is the Worker Animation closes when the long running task completes, but BEFORE the data bindings update.
So the end result is you get the worker animation displaying as expected while the task runs, but the data binding update takes a good 4-5 seconds or even longer for large datasets for all the tree data and during this time, the application is not in "working animation mode" and just freezes.
Is there a way I can have my worker animation continue to run not only for the Long running Method, but for the associated data binding updates from OnPropertyChanged as well?
Consider using BusyIndicator from Extended WPF toolkit. It should provide functionality you described. It has IsBusy property which you can bind to property in your ViewModel and set it to False after all work is done.
You can always change the style of BusyIndicator same way as you do with other controls. In my solutions I always use this control along with BackgroundWorker class from System.ComponentModel and I usually set IsBusy=false at the end of RunWorkerCompleted
private void LongRunningMethod()
{
this.IsBusy = true;
var worker = new BackgroundWorker();
worker.DoWork += this.LongMethodDoWork;
worker.RunWorkerCompleted += this.RunWorkerCompleted;
worker.RunWorkerAsync();
}
private void LongMethodDoWork(object sender, DoWorkEventArgs doWorkEventArgs)
{
...
}
private void RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs runWorkerCompletedEventArgs)
{
...
this.IsBusy = false;
}
Thanks all for the answers. I've actually come across a solution that may be a bit controversial as some would construe it is a little bit of a hack, but it does exactly what I want it to do and there seems to be no other way to do it, so to me that is a code solution, not a hack.
I'm using the WPFBackgroundProgressIndicator open source project I downloaded from codeproject (I think) which has the option to show the busy indicator in the main content with or without a fade out, or as a popup and it runs as a background thread which is ideal and why I chose it.
The problem was that when you run a long running method, the code execution completes synchronously but all the binding OnPropertyChanged("") updates run asychronously and queue on the Dispatcher thread, so your work method completes before the WPF controls have a chance to call the Getters of the dependency properties, to retrieve the new value. What you need to do is effectively "block" until all the Dispatcher events have completed and that is why not everyone will like this solution as it "blocks", but then that is exactly what I am trying to do. I WANT to block the application until the full update has completed as I dont want the user to be able to do anything visually while data is still rendering, so that is my requirement. Clean blocking is preferable to messy interaction.
So the solution, believe it or not, is a single line of code just after the work method call. It is as follows.
Application.Current.Dispatcher.Invoke(new Action(() => { }), DispatcherPriority.ContextIdle, null);
Which as you can see effectively queues a new task on the Dispatcher thread and blocks current code execution until it finishes, but as you give it the lowest priority, this call will wait until all OTHER dispatcher execution finishes, ie all rendering completes. Once render is complete, this line will be executed and you will exit with all rendering complete. The full method I have used it in context is below. I welcome your thoughts and discussion on this approach.
public void LongRunningTaskWithFade(BusyDecorator busy, Action longTask)
{
if (loading) return;
loading = true;
busy.FadeTime = TimeSpan.Zero;
busy.IsBusyIndicatorShowing = true;
// in order for setting the opacity to take effect, you have to delay the task slightly to ensure WPF has time to process the updated visual
Application.Current.Dispatcher.BeginInvoke(new Action(() =>
{
try
{
longTask();
Application.Current.Dispatcher.Invoke(new Action(() => { }), DispatcherPriority.ContextIdle, null);
}
finally
{
HideBusyDisplay(busy);
}
}), DispatcherPriority.Background);
}
I have Datagrid and I do something like:
Me.Cursor = Wait
Datagrid.ItemsSource = GetData()
Me.Cursor = Nothing
The problem is that there is a (relatively) large delay between setting the .ItemsSource and the moment when the rows actually rendered. So my cursor is reset to normal much too early.
Is there some kind of event that is raised when the Datagrid is finished loading/rendering the data? I know there is a _LoadingRow event, but it fires during the data load, not when the loading is completed?
I had the same issue (look here), and I solved it by placing this code after I changed the ItemsSource:
Dispatcher.InvokeAsync(() => { System.Windows.Input.Mouse.OverrideCursor = null; },
DispatcherPriority.ApplicationIdle);
It basically waits for the application to become idle before changing the cursor back to default. Using a FrameworkElement.Loaded event was not enough because it wouldn't get raised when I made changes to the ItemsSource, only when the datagrid was first loaded.
You may take a look at BeginInit() and EndInit() methods
I'd like to load Xaml from code running in a background thread.
I understand I would have to sync with the dispatcher. However, it fails (throws an exception).
Why?
Here is the code
public MainWindow()
{
InitializeComponent();
Thread thread = new Thread(new ThreadStart(delegate
{
Dispatcher.Invoke(new Action(delegate
{
Content = XamlReader.Parse(
"<Button xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation'
Content='Hello World'/>");
}));
}));
thread.Start();
}
As Pavlo mentioned, you need to also set your content within the Dispatcher.
However, I will say - this is fairly useless.
Remember, when you call Dispatcher.Invoke or BeginInvoke, you're explicitly saying to run that code on the UI thread. By starting a background thread that does nothing but invoke back to the UI thread, you're effectively doing the same work on the UI thread, with the disadvantage of extra overhead being added to the system as well as harder debugging. In this case, you should just load the file directly.
This seems like a bad idea for a couple reasons. Are you expecting to get XAML fragments from a database or some other storage and you can't create the instances of these controls in C#? You could just create a Button directly.
Are you able to allow the data to drive your visualization? A good example of this is having a collection of ICommand objects (CommandViewModel, RelayCommand, etc) and a CommandView that you want to use to represent your command? In this case, it could be a <Button> with a binding to the CommandViewModel Title or Content property.
You're background thread could then be used to drive the population of data (collections, properties) and you're UI would be designed to flexibly accommodate the expected data patterns.
I use a browse for files dialog to allow a user to select multiple images. If a lot of images are selected, as expected it takes a bit. Below is an example of what I do with the selected images. I loop through the filepaths to images and create an instance of a user control, the user control has an Image control and a few other controls. I create the instance of this control then add it to a existing stackPanel created in the associating window xaml file. The example just below works fine, but I'm trying to understand BackGroundWorker better, I get the basics of how to set it up, with it's events, and pass back a value that could update a progress bar, but because my loop that takes up time below adds the usercontrol instance to an existing stackPanel, It won't work, being in a different thread. Is BackGroundWorker something that would work for an example like this? If so, what's the best way to update the ui (my stackpanel) that is outside the thread. I'm fairly new to wpf and have never used the BackGroundWorker besides testing having it just update progress with a int value, so I hope this question makes sense, if I'm way off target just let me know. Thanks for any thoughts.
Example of how I'm doing it now, which does work fine.
protected void myMethod(string[] fileNames) {
MyUserControl uc;
foreach (String imagePath in fileNames) {
uc = new MyUserControl();
uc.setImage(imagePath);
stackPanel.Children.Add(uc);
progressBar.Value = ++counter;
progressBar.Refresh();
}
}
below this class i have this so I can have the progressBar refresh:
public static class extensionRefresh {
private static Action EmptyDelegate = delegate() { };
public static void Refresh(this UIElement uiElement) {
uiElement.Dispatcher.Invoke(DispatcherPriority.Background, EmptyDelegate);
}
}
Check out this article on
Building more responsive apps with the Dispatcher
Now that you have a sense of how the Dispatcher works, you might be surprised to know that you will not find use for it in most cases. In Windows Forms 2.0, Microsoft introduced a class for non-UI thread handling to simplify the development model for user interface developers. This class is called the BackgroundWorker
In WPF, this model is extended with a DispatcherSynchronizationContext class. By using BackgroundWorker, the Dispatcher is being employed automatically to invoke cross-thread method calls. The good news is that since you are probably already familiar with this common pattern, you can continue using BackgroundWorker in your new WPF projects
Basically the approach is
BackgroundWorker _backgroundWorker = new BackgroundWorker();
// Set up the Background Worker Events
_backgroundWorker.DoWork += _backgroundWorker_DoWork;
_backgroundWorker.RunWorkerCompleted += _backgroundWorker_RunWorkerCompleted;
// Run the Background Worker
_backgroundWorker.RunWorkerAsync(5000);
// Worker Method
void _backgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{
// Do something
}
// Completed Method
void _backgroundWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
// Doing UI stuff
if (e.Cancelled)
{
statusText.Text = "Cancelled";
}
else if (e.Error != null)
{
statusText.Text = "Exception Thrown";
}
else
{
statusText.Text = "Completed";
}
}
Using a BackgroundWorker alone won't solve your issue since elements created during the DoWork portion will still have originated from a non-UI thread. You must call Freeze on any objects you intend to use on another thread. However only certain UI objects will be freezable. You may have to load in the images as BitmapImages on the background thread, then create the rest of your user control on the UI thread. This may still accomplish your goals, since loading in the image is probably the most heavyweight operation.
Just remember to set BitmapImage.CacheOption to OnLoad, so it actually loads up the image when you create the object rather than waiting until it needs to be displayed.
Is there any way how to do
ICollectionView.Refresh()
or
CollectionViewSource.GetDefaultView(args.NewValue).Refresh();
in a separate thread?
I know I can use dispatcher, but this collection is binded to a ListView and it throws cross thread Exceptions.
The reason why I need a second thread is, that I have Control which displays a list of IMyItems. When filtering this Collection (by user text change input), I want to be able to display my animation that CollectionView is changing.
You can't!
All UI operations must happen on the user interface thread, and nearly every call inside of WPF's DispatcherObject (and all controls in that hierarchy) are regularly going to be calling CheckAccess().
You might want to consider using an ObservableCollection to help keep your data up-to-date, if you're doing processing in a background thread or BackgroundWorker.
How about using the Dispatcher to do work with background priority?
Dispatcher.Invoke(DispatcherPriority.Background,
() => { CollectionViewSource.GetDefaultView(args.NewValue).Refresh(); }
);
I hacked up a quick method to invoke actions on wpf dispatchable objects (all wpf controls inherit from DispatcherObject)
public static void InvokeWpf(DispatcherObject dispatchable, Action action, bool async)
{
// DispatcherOperationCallback is optimized for wpf invoke calls
DispatcherOperationCallback toDo = delegate{ action(); return null; };
if (!dispatchable.CheckAccess())
{
if (async)
dispatchable.Dispatcher.BeginInvoke(toDo, null);
else
dispatchable.Dispatcher.Invoke(toDo, null);
}
else
{
toDo(null);
}
}
Usage:
InvokeWpf(listView,
() => CollectionViewSource.GetDefaultView(listView).Refresh(),
false);