0

I've come across this exception before:

The calling thread cannot access this object because a different thread owns it.

Usually it's been caused by event handlers that have asynchronous methods. And to fix this problem, in the past, usually all I've had to do is change something like this:

myObject.CustomEvent += MyCustomEventHandler;

To something like this:

myObject.CustomEvent += (s, e) => Dispatcher.Invoke(() => MyCustomEventHandler(s, e));

And that's all well and good when all of this code lives within the same WPF application. However, my solution is split up into multiple projects, one of which is a generic "Utilities" library that has some common functions I use frequently. In this library, I have a special "Timer" class that is a wrapper for executing a given method on a regular interval.

So it's got code that looks like this:

timer.Elapsed += OnTimedEvent;

I tried to change it to this, as I was used to doing:

timer.Elapsed += (s, e) => Dispatcher.Invoke(() => OnTimedEvent(s, e));

However, that wouldn't compile. It says:

Cannot access non-static method 'Invoke' in a static context

So, I think that Dispatcher is somehow an alias for the current dispatcher inside of a WPF application, but not otherwise? (Or something like that?) So my next attempt was to change the code to this:

timer.Elapsed += (s, e) => Dispatcher.CurrentDispatcher.Invoke(() => OnTimedEvent(s, e));

That does compile, thankfully. However, it doesn't solve my problem. I'm still seeing those nasty InvalidOperationExceptions with the same message as before:

The calling thread cannot access this object because a different thread owns it.

So I successfully accomplish nothing by adding CurrentDispatcher. I must confess that I have a bit of a knowledge gap when it comes to some of this threading stuff, so any counsel you can offer is much appreciated!

i3arnon
  • 113,022
  • 33
  • 324
  • 344
soapergem
  • 9,263
  • 18
  • 96
  • 152
  • I have nominated this for reopening because in my opinion, those who voted to close it have misunderstood the fundamental question. I.e. the OP is not really asking simply how to get an instance of `Dispatcher`, but rather how to deal with this specific scenario. The proposed duplicate does not address this question at all, never mind provide the answer that was accepted here. – Peter Duniho Apr 30 '15 at 15:48
  • Thanks @PeterDuniho! And thanks for your thorough answer as well. I probably could have phrased the subject of the question better, but then I wasn't really sure how to say it in a concise way that didn't immediately sound like one of the many duplicates. – soapergem Apr 30 '15 at 16:05
  • Happy to help. And for the record, while the title might have been phrased differently, IMHO it was reasonably clear. Indeed, the key here is "in a library" which you did state in the title itself, and which is the core of the reason this is not just the usual "call the Dispatcher" question. – Peter Duniho Apr 30 '15 at 16:09

1 Answers1

1

What to do depends on your library, but in most cases the right solution is to do nothing, not in the library itself.


At some point, if you are getting that exception, then some UI object is being called to handle the event. It is that UI object that should concern itself with calling Dispatcher.Invoke().

Note that Dispatcher is not an "alias". In the contexts in which you've used it before, it was a member of the object in which you were writing the code.

The static Dispatcher.CurrentDispatcher property returns the Dispatcher object for the current thread. Of course, if the code is running in a thread other than the UI thread where you want to invoke the operation, that's the wrong Dispatcher object.

But that does suggest an approach for code where your library is somehow specifically intended to deal the issue of cross-thread invocation. For examples in .NET, see classes like BackgroundWorker and Progress<T>. If you are writing a similar type, then you can capture the Dispatcher object when your class is instantiated (i.e. in the constructor). Save the value of Dispatcher.CurrentDispatcher, and use that saved object reference when you need to call Invoke().


But really, that scenario is very rare. Most of the time, one is writing library code that would otherwise have zero dependency on the UI, its thread, its Dispatcher or anything else UI related. In that much more common case, the right thing to do is not do anything in the library itself. Instead, let the client code of the library deal with it, if necessary.

Doing it that way simplifies the library, and allows it to be used in any variety of scenario, with or without a Dispatcher. And of course, when you leave the responsibility to the UI object, it has the Dispatcher property you are used to using, so you don't need to mess around with e.g. Application.Current.Dispatcher.

Peter Duniho
  • 68,759
  • 7
  • 102
  • 136