The title sounds like some easy well-known problem, but please check out this:
I've got some WPF window that handles a list of Threads and shows ProgressBar for each Thread. The invoked GUI refresh is working for most threads showing right number of percent and also for unknown progress the IsIndeterminate state is animated. After the thread is done some animation fades out the ProgressBar.
However, for some of my heavy tasks the ProgressBar is not visually updated. For example, the IsIndeterminate state refreshes only if I force the GUI to redraw by some mouseover events or by moving the form. The fade out animation shows the same problem.
I think this is no usual stucking because the UI thread is not blocked by further operations (there's only one invoke setting IsIndeterminate = true). Until now, I wasn't able to find out what's the different between heavy tasks that result in this behavoir and tasks that do not.
Please notice that the replacement of the Thread by a BackgroundWorker shows exactly the same problem (I'm also not sure why people say BackgroundWorker will not freeze the GUI but Threads allegedly do - this seems not entirely right). Please also notice that although the thread is paused by Thread.Suspend() (yes, I know it's obsolete but this is an essential feature I need, since the task content is unknown) the GUI will not show up the IsIndeterminate animation if no other GUI element forces the refresh of the window.
Any ideas what that problem might be and how to fix it? I just need the usual refreshing rate for drawing animated controls...
Related
From a production application, we notice that our WPF buttons fire the ICommand.Execute method twice on fast double click.
Now, on every Command, the application is covered with a full-screen spinner animation, preventing any further interaction with the application.
This github repo contains a minimalistic repro of the issue. Note that:
when the Button's Command fires, the "IsBusy" flag is set to true
as a consequence, the BusyIndicator overlay will be shown
as a consequence, the Button cannot be pressed again until after 300ms
However, especially on slow computers, when fast double-clicking (really fast, like gaming fast that is), it is possible to fire the command twice without the BusyIndicator blocking the second call (this can be seen if the output shows 2 'click' lines right after one another).
This is unexpected behavior to me, as the IsBusy flag is set to true right away on the UI thread.
How come a second click is able to pass through?
I would expect the IsBusy Binding to show the overlay on the UI thread, blocking any further interaction?
The github sample also contains 2 workarounds:
using the ICommand.CanExecute to block the Execute handler
using the PreviewMouseDown to prevent double clicks
I'm trying to understand what the issue is.
What work-around would you prefer?
Diagnosis
This is only my guess and not a solid and confirmed info, but it seems that when you click the mouse button, the hit-testing is done immediately, but all the mouse related events are only scheduled to be raised (using the Dispatcher I presume). The important thing is that the control that is clicked is determined at the time the click occurred, and not after the previous click has been completely handled (including all UI changes that potentially follow).
So in your case, even if the first click results in showing the BusyIndicator covering (and thus blocking) the Button, if you manage to click for the second time before the BusyIndicator is actually shown (and that does not happen immediately), the click event on the Button will be scheduled to be raised (which will happen after the BusyIndicator is shown), causing the command to be executed again even though at that point the BusyIndicator will possibly be blocking the Button.
Solution
If your goal is to prevent command execution while the previous one is still executing the obvious choice is to make the Command.CanExecute result depend on the state of the IsBusy flag. Moreover, I wouldn't even call it a workaround, but a proper design.
What you're facing here is a clear-cut example of why you shouldn't make your business logic rely on UI. Firstly, because rendering strongly depends on the machine's processing power, and secondly because covering a button with another control by far does not guarantee the button cannot be "clicked" (using for example UI Automation framework).
I'm overriding WPF's OnRender to draw complex graphics. This may rarely take a long time. I would like to indicate to the user that the app did not crash, but is "merely" taking a long time to render.
How would I do that? It seems not possible to modify the UI in any way during the OnRender call.
You are talking about placing a "Busy Indicator" on top of your drawing.
Just place a half transparent grid on top with the writing "Loading..."
and you're done.
Bind its visibility to some bool that you update once when entering the complex rendering, and once when finished.
Or put a spinning Ellipse with gradient background if you want to see motion..
Since the OnRender method will execute on the UI thread you cannot do anything else such as displaying an interactive ProgressBar or respond to user input during the execution of your code.
What you can do is to pop up a new window that launches in a separate thread and display this one right before you begin to draw your complex graphics.
Please refer to my answer in the following similar question for more information about this.
Wait screen during rendering UIElement in WPF
Once the OnRender method has returned you then close the temporary "loading" window:
Can I stop WPF from executing UI actions out of the order in my code
We are facing an issue, wherein we need to suspend grid painting for some time. We are using devexpress DXGrid bound to XPInstantFeedbacksource. We have a requirement of refreshing source every 2-3 seconds to get the updated realtime data which is huge (around 40 -50 thousand records in a day).
However the refresh method of the above mentioned source binds the grid asynchronously and when it does so, it causes some kind of flickering onto grid. Internally it captures layout of grid before refresh and renders it back in postrefresh phase.
I have tried many things like wrapping the refresh call in bigindataupdate and enddataupdate, but it doesn't seem to work.
However, one thing which looks interesting to me is using Win32 api to suspend layout painting for some moments and resuming it.
I found something at
How do I suspend painting for a control and its children?
which works well for Winforms, but in WPF as far as I know, individual controls share window handle. And method call
SendMessage(parent.Handle, WM_SETREDRAW, false, 0);
uses control handle to interact with WIN32. Also, I observed that if I suspend layout for window underlying grid still gets painted which is strange to me.
I just want to know , if I am going in right direction by suspending grid layout to avoid flickering and if yes please suggest some way to achieve this.
Thanks,
Gurpreet
What the tittle says, I have lengthy for loop in which based on some conditions I add objects to a Canvas. I want the objects to show as they are added but they show after the loop is done? Does anyone know why and how I can fix this?
Also: the textbox.text property doesn't get updated too.
The UI won't update while you are tying up the UI thread, you need to return control to allow it to render.
You should try to move long-running operations to a background thread if possible - say using a BackgroundWorker - and update the UI every so often. This should result in a much more responsive UI.
If you really need to do some lengthy work on the UI thread (eg you're adding a large number of controls that are slow to render) you'll have to break it up into manageable portions. You can wait for the CompositionTarget.Rendering event to know when the UI has rendered and you can continue. But it's much better to offload work to a background thread if you can.
I'm creating a custom charting control and I would like to have the possibility of displaying some sort of wait bar while other commands are running (i.e. chart is being created).
I'm using ProgressBar (System.Windows.Forms.ProgressBar in marquee mode) as a part of this control. I do not need to update the state of the progress bar, I just want it to move over and over until the chart is created.
Right now I'm using it in following scheme:
- Start wait bar (ProgressBar appears and starts running)
- Call charting methods
- When the chart is ready, the wait bar will being hidden.
The problem is: Some charting methods are really computational demanding and the wait bar freezes in such moments. How can I avoid these freezes? Should I use some kind of threading/background worker? And if yes, then what is the simplest way to do it?
Note, that I do not need to change the state of the progress bar while the chart is being prepared. I just need the wait bar to start, run during all computations and stop after that.
EDIT
OK, as suggested, I created a separate thread for these demanding computations to avoid freezes.
But how to wait for a thread to finish and do not freeze the GUI?
I tried, as suggested here, something like that:
Thread t = new Thread( () => { DoSomeLongAndDemandingTask(withParameters); });
t.Start();
t.Join()
// do something that needs to be done after thread finishes
InvokeMeAfterThreadFinished();
But it freezes the GUI. Is there any other way to avoid these freezes?
You've answered your own question - typically the answer is to move the computation onto a background thread. There is a WinForms component called the BackgroundWorker, does a lot of the lifting for you:
http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
http://dotnetperls.com/backgroundworker
Note that you won't be able to access UI components from the background thread, you need to Control.Invoke onto the UI thread to get access to UI controls. This is heavily talked about (and solutions provided) on the net so Googling will be easy for this.
Alternatively, sometimes a background thread is unworkable (not sure why), so you can use Application.DoEvents() - if memory serves, this processes pending messages on the message queue (including control painting, UI updating). If you only do a little work that causes jittering, this could be a faster and simpler option - though not advised too often.
Using the BackgroundWorker class is the simplest way to perform a background computation.
However, just be careful that the charting methods you are running in the background do not update the UI. All updates to the UI itself must be performed by the UI thread. So a background thread will need to "marshall" such calls to the UI - see Control.Invoke for a starting point on that.