What good is an indeterminate progress bar that is frozen because of course its on the same thread? Is there a way to keep it running? Possibly multi-threading?
+1
A:
Threading is almost certainly the solution, yes - or asynchronous operations. You definitely shouldn't be performing a long-running task in the UI thread.
One common pattern is to use BackgroundWorker for the background task - it makes it particularly easy to report progress back to the UI thread.
Jon Skeet
2010-10-27 19:31:20
The BackgroundWorker pattern is the exact opposite of what I need. I need to display the progress bar in an alternate thread. I can't just wrap my processes in a BackgroundWorker, because it is not my stuff that's taking a long time. Its WPF layout that is taking the time.
Jordan
2010-10-28 13:02:28
@Jordan: It would have been helpful to explain that to start with. It's *possible* that you could create a new UI thread for a whole separate window - within a single window I think you're likely to have problems though.
Jon Skeet
2010-10-28 13:13:20
That's exactly what I'm looking to do. How?
Jordan
2010-10-29 12:58:22
A:
Code I've used in this situation
ProgressIndicator.Visibility = System.Windows.Visibility.Visible;
ThreadPool.QueueUserWorkItem
(
delegate
{
// Perform slow action
Thread.Sleep(5000);
this.Dispatcher.Invoke(
new Action(delegate()
{
// Insert UI related activity here.
// ....
ProgressIndicator.Visibility = System.Windows.Visibility.Collapsed;
}
));
}
);
grantnz
2010-10-28 10:14:05
I haven't had problems with WPF's layout being slow. I presume you have some sort of recursive layout situation (or a very large number of controls). Can you give more info on the layout problem?
grantnz
2010-10-28 21:56:14
I have a list of a few hundred things that need to be put in a `ScrollViewer`. I can't use virtualizing because the viewer needs to scroll smoothly as this is a touch screen application, and virtualizing forces integral scrolling.
Jordan
2010-10-29 12:59:44
Interesting problem, but you may want to add some detail to the original question.
FrustratedWithFormsDesigner
2010-10-29 13:43:33
A:
Not sure about the details of your problem but I had a similar-sounding problem (maybe?) where I had a ListView with many (hundreds) of thumbnails that needed to be displayed. The thumbnails were generated from digital photos on the file-system so creating that many thumbnails would have locked up the UI while they all loaded. I created all of the objects in the ListView with a placeholder image (tiny JPG with the string "Loading..."), and just enough data so that the background worker would then update each object in the ListView with the thumbnail, and possibly other data from the file (the data for the placeholder objects came from a simple database query). The user gets a UI that's responsive while the loading occurs. This worked well because loading the placeholder data for hundreds of objects was quick enough (a few seconds), compared to possibly minutes for very large sets of data. I don't know enough about your situation to know if this would work...
FrustratedWithFormsDesigner
2010-10-29 15:53:51