-1
  1. It is well-known that threads share the same address space.
  2. Also it is well known that we cannot directly update UI from different thread(we have to use control.Invoke instead).

So my question is WHY this UI objects(label, textbox etc.) are so special ? Why we can set some properties or call some methods for usual classes, but cannot do it for UI classes ?

Dmitry Bychenko
  • 180,369
  • 20
  • 160
  • 215
Disappointed
  • 1,100
  • 1
  • 9
  • 21
  • This is how WPF is designed. It assumes that all UI calls are within the same thread. – helb Aug 10 '15 at 08:48
  • 1
    @helb This isn't about WPF per-se. It's in the fact UI elements in windows are COM objects. And COM is thread-affine, meaning you can only "touch it" from the thread which created it. – Yuval Itzchakov Aug 10 '15 at 08:49
  • See this question: http://stackoverflow.com/questions/1293402/why-does-wpf-require-a-stathread-attribute-to-be-applied-to-the-main-method – helb Aug 10 '15 at 08:51

1 Answers1

-1

From MSDN :

Windows Presentation Foundation (WPF) is designed to save developers from the difficulties of threading. As a result, the majority of WPF developers won't have to write an interface that uses more than one thread. Because multithreaded programs are complex and difficult to debug, they should be avoided when single-threaded solutions exist.

https://msdn.microsoft.com/en-us/library/vstudio/ms741870(v=vs.100).aspx

EDIT:

As an answer to your comment -

"Does your quote explains something ???!!"

I thought it was clear enough:

You -

my question is WHY this UI objects(label, textbox etc.) are so special ? Why we can set some properties or call some methods for usual classes, but cannot do it for UI classes ?

MSDN -

Because multithreaded programs are complex and difficult to debug, they should be avoided when single-threaded solutions exist.

I deleted the second paragraph, I didn't notice I copied it too.

shay__
  • 3,815
  • 17
  • 34