0
votes

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?

2

2 Answers

0
votes

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);
0
votes

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()));