Link Details

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.

Posted by amitbet  |   Jun 26 2013 / 10:30

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.

Comments

User 851745 avatar

Greg Brown replied ago:

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.

Reply 0 votes
User 265881 avatar

Topnotch replied ago:

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

Reply 0 votes
User 851745 avatar

Greg Brown replied ago:

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.

Reply 0 votes
User 1137257 avatar

amitbet replied ago:

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.

Reply 1 votes

Recommended Links

Scala
Written by: Ryan Knight
Featured Refcardz: Top Refcardz:
  1. Apache Hadoop
  2. Play
  3. Akka
  4. Debugging JavaScript
  5. Design Patterns
  1. Apache Hadoop
  2. REST
  3. Java
  4. Git
  5. Java Performance
Connect with DZone