Fixed the remaining issues in the ContainerListView control; minor documentation improvements

git-svn-id: file:///srv/devel/repo-conversion/nuwi@28 d2e56fa2-650e-0410-a79f-9358c0239efd

Source/AsyncProgressBar/AsyncProgressBar.Test.cs

@@ -0,0 +1,71 @@
+#region CPL License
+/*
+Nuclex Framework
+Copyright (C) 2002-2009 Nuclex Development Labs
+
+This library is free software; you can redistribute it and/or
+modify it under the terms of the IBM Common Public License as
+published by the IBM Corporation; either version 1.0 of the
+License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+IBM Common Public License for more details.
+
+You should have received a copy of the IBM Common Public
+License along with this library
+*/
+#endregion
+
+#if UNITTEST
+
+using System;
+using System.IO;
+using System.Windows.Forms;
+
+using NUnit.Framework;
+
+using Nuclex.Support;
+
+namespace Nuclex.Windows.Forms {
+
+  /// <summary>Unit Test for the asynchronously updating progress bar</summary>
+  [TestFixture]
+  public class AsyncProgressBarTest {
+
+    /// <summary>
+    ///   Verifies that asynchronous progress assignment is working
+    /// </summary>
+    [Test]
+    public void TestProgressAssignment() {
+      using(AsyncProgressBar progressBar = new AsyncProgressBar()) {
+
+        // Let the control create its window handle
+        progressBar.CreateControl();
+        progressBar.Minimum = 0;
+        progressBar.Maximum = 100;
+        
+        Assert.AreEqual(0, progressBar.Value);
+        
+        // Assign the new value. This will be done asynchronously, so we call
+        // Application.DoEvents() to execute the message pump once, guaranteeing
+        // that the call will have been executed after Application.DoEvents() returns.
+        progressBar.AsyncSetValue(0.33f);
+        Application.DoEvents();
+        
+        Assert.AreEqual(33, progressBar.Value);
+
+        progressBar.AsyncSetValue(0.66f);
+        Application.DoEvents();
+
+        Assert.AreEqual(66, progressBar.Value);
+
+      }
+    }
+
+  }
+
+} // namespace Nuclex.Windows.Forms
+
+#endif // UNITTEST

Source/AsyncProgressBar/AsyncProgressBar.cs

@@ -38,16 +38,16 @@ namespace Nuclex.Windows.Forms {
       // whenever I see it :)
       Interlocked.Exchange(ref this.newProgress, -1.0f);
     }
-
+    
     /// <summary>Called when the progress bar is being disposed</summary>
     /// <param name="sender">Progress bar that is being disposed</param>
     /// <param name="arguments">Not used</param>
     private void progressBarDisposed(object sender, EventArgs arguments) {
 
       // CHECK: This method is only called on an explicit Dispose() of the control.
-      //        Microsoft officially states that it's allowed to call Control.BeginInvoke()
-      //        without calling Control.EndInvoke(), so this code is quite correct,
-      //        but is it also clean? :>
+      //   It is legal to call Control.BeginInvoke() without calling Control.EndInvoke(),
+      //   so the code is quite correct even if no Dispose() occurs, but is it also clean?
+      //   http://www.interact-sw.co.uk/iangblog/2005/05/16/endinvokerequired
 
       // Since this has to occur in the UI thread, there's no way that updateProgress()
       // could be executing just now. But the final call to updateProgress() will not