Link Details

Link 988121 thumbnail
User 1137257 avatar

By amitbet
Published: Jun 26 2013 / 10:30

Have you ever experienced an inaccurate progress bar? have you ever interacted with an unresponsive UI, with no progress indication at all? * A progress bar that Reported 10 minutes remaining when you started it, 30 minutes ago * A progress bar that Jumps from 30% to 95% and lingers there for an hour * A main window that freezes up, with no sign of life while running a lengthy job Inaccurate progress reporting may lead to user frustration and physical damage to equipment... Today I want to examine how you can create a responsive, accurate progress/"processing" indications to alleviate some of these issues. Keep reading to find out how you can free your Progress bar from the shackles of the UI thread and create a more fluent user experience in your application.
  • 7
  • 1
  • 1018
  • 634
User 851745 avatar

Greg Brown replied ago:

0 votes Vote down Vote up Reply

Most UI toolkits that I have worked with require that all UI updates be performed on the main thread (via the event loop). So updating the progress bar from another thread directly (without posting an event to the event queue) is not recommended. The "right" fix is to ensure that the UI thread is never so busy that it can't process events.

User 265881 avatar

Topnotch replied ago:

0 votes Vote down Vote up Reply

In .NET it is expected that you will run any code that updates the UI from a separate thread than the UI thread.

User 851745 avatar

Greg Brown replied ago:

0 votes Vote down Vote up Reply

My understanding is that you should not be directly updating your control state from the background thread. That was definitely the case in Win32 and I'm guessing it is true for WinForms and WPF as well. However, maybe .NET provides a way to do this programmatically that makes it seem like you are actually modifying the controls in the background.

User 1137257 avatar

amitbet replied ago:

1 votes Vote down Vote up Reply

you are all correct: 1) updating UI components from a worker thread will result in an exception (all UI toolkits including the regular framework controls) 2) the right fix (as mentioned in the article) is truely using a background thread to do the work and posting updates to the model which will then update the graphics via binding (if not possible by binding, than by invocation into the main thread manually and updating). 3) there are situations where you have problematic legacy code, and the "right" fix will not apply, you can use my trick 4) the actual trick is creating a new thread and a new message pump that lives on it, then creating the progress bar on that pump and not on the main pump (so it's independent from the main thread) 5) my trick works in both WPF and Winforms, as you can see when you compile & run the demo project. Amit.

Add your comment

Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Apache Hadoop
Written by: Piotr Krewski
Featured Refcardz: Top Refcardz:
  1. Play
  2. Akka
  3. Design Patterns
  4. OO JS
  5. Cont. Delivery
  1. Play
  2. Java Performance
  3. Akka
  4. REST
  5. Java