views:

38

answers:

2

I'm aware, and use, the xxx.Dispatcher.Invoke() method to get the background thread to manipulate GUI elements. I think I'm bumping up against something similar, but slightly different, where I want a long running background task to construct a tree of objects and when done hand it to the GUI for display.

Attempting to do that results in an InvalidOperationException, "due to the calling thread cannot access this object because a different thread owns it." Curiously, this doesn't happen with simple type.

Here's some example code that demonstrates a trivial case the throws the exception. Any idea how to work around this? I'm pretty sure that the problem is the background thread owns the factory constructed object and that the foreground GUI thread can't take ownership, although it works for more simple system types.

private void button1_Click(object sender, RoutedEventArgs e) 
{  
   // These two objects are created on the GUI thread
   String abc = "ABC";  
   Paragraph p = new Paragraph();

   BackgroundWorker bgw = new BackgroundWorker();

   // These two variables are place holders to give scoping access
   String def = null;
   Run r = null;

   // Initialize the place holders with objects created on the background thread
   bgw.DoWork += (s1,e2) =>
     {
       def = "DEF";
       r = new Run("blah");
     };

   // When the background is done, use the factory objects with the GUI
   bgw.RunWorkerCompleted += (s2,e2) =>
     {
        abc = abc + def;         // WORKS: I suspect there's a new object
        Console.WriteLine(abc);  // Console emits 'ABCDEF'

        List<String> l = new List<String>();  // How about stuffing it in a container?
        l.Add(def);                           // WORKS: l has a reference to def

        // BUT THIS FAILS.
        p.Inlines.Add(r);  // Calling thread cannot access this object
     };

   bgw.RunWorkerAsync();
}

The grand scope of the problem is that I have a large document that I'm constructing on the fly in the background and would love for the GUI to show what's been generated so far without having to wait for completion.

How can a background worker act as an object factory and hand off content to the main thread?

Thanks!

+3  A: 

You are trying to create the Run in the background thread, but Run is a FrameworkContentElement which inherits from DispatcherObject and thus is bound to the thread that created it.

Franci Penov
Ah! So that explains why it's possible to pass some objects and not others. Since String isn't inherited from DispatcherObject, it worked.I'm curious is there any side-behavior for wanting to ever use DispatcherObject on my own objects? For instance, managing thread-specific resources?
Walt Stoneburner
Yes, inheriting from `DispatcherObject` can be used to create thread-bound resources with support for Invoke.
Franci Penov
+1  A: 

As Franci said, Run is a DispatcherObject, so it is only updatable on the thread that created it. The code should run if it calls Dispatch.Invoke or Dispatcher.BeginInvoke like this:

    private void button1_Click(object sender, RoutedEventArgs e)
    {
        var button = sender as Button;

        string abc = "ABC";
        var p = new Paragraph();

        var bgw = new BackgroundWorker();

        String def = null;
        Run r = null;

        bgw.DoWork += (s1, e2) =>
          {
              def = "DEF";
              button.Dispatcher.BeginInvoke(new Action(delegate{r = new Run("blah");}));
          };

        bgw.RunWorkerCompleted += (s2, e2) =>
          {
              abc = abc + def;
              Console.WriteLine(abc); 
              var l = new List<String> { def };
              p.Inlines.Add(r);  // Calling thread can now access this object because 
                                 // it was created on the same thread that is updating it.
          };

        bgw.RunWorkerAsync();
    }
JoshVarga
Thank you -- having the code example helps visualize it.Question: I thought there was some non-trivial overhead crossing between threads with the dispatcher queue. Is this code simply controlling ownership of the object, or is there actually going to be a performance hit on the GUI itself.Put another way, if my background threads dispatch back to the GUI thread, am I gaining anything above not doing it on the GUI thread to start?The goal is to keep the GUI responsive while work is being done. Time to look into low priority requests, I guess. Thanks.
Walt Stoneburner
Thread-switching is costly. However, since your background thread switches between the background and the UI thread, the end result is that the tree will be created slower than if you run the code on the UI thread only; however, the UI thread will be (somewhat) responsive to the user input while building the UI tree. It's a trade-off and you have to figure out if it's worth it for your scenario.
Franci Penov