2

From my reading:

WPF objects use an executing thread to store state (known as thread affinity). This means they have to communicate on the same thread they were created on. The DispatcherObject allows these WPF objects to communicate on the same thread.

  • Is the above correct? The stuff about storing state came from the msdn link below.
  • What are the WPF objects communicating to each other? I read something about a message pump. Does that mean they are passing events to each other and by being on a single thread, it ensures that they are passed in order?
  • What specific state are they storing?

Some details: http://msdn.microsoft.com/en-us/library/ms750441.aspx#System_Threading_DispatcherObject

i8abug
  • 1,692
  • 3
  • 19
  • 31
  • possible duplicate of [what is a dispatcher](http://stackoverflow.com/questions/2627811/what-is-a-dispatcher) – Chris Shain Feb 19 '12 at 23:33
  • also http://stackoverflow.com/questions/159015/what-is-the-use-of-a-dispatcher-object-in-wpf – Chris Shain Feb 19 '12 at 23:33
  • I don't think either of those questions define the state that is being stored. Or mention anything about a message pump. I'm looking for a more detailed answer as to the inner workings of DispatchObjects. – i8abug Feb 19 '12 at 23:39

1 Answers1

1

The section you linked to actually explain this: Theoretically, WPF might not need thread affinity. But many old objects do, and WPF needs to work nicely with them.

svick
  • 236,525
  • 50
  • 385
  • 514
  • so do you know what state information is being stored with the thread id? Or what types of state information? I'm really lost on that part. I would like to know why they need thread affinity (as opposed to that they need thread affinity) – i8abug Feb 20 '12 at 16:19