Control.Invoke executes the specified delegate on the thread that owns the control’s underlying window handle.
For years I have just accepted that this is the way it has to be, but I have never understood why.
The only thing I can think of is that the code is terribly thread unsafe, and instead of just adding a little synchronization in the control code, the framework just dissallows it and forces us down this route – throwing the baby out with the bath water!
-
Is it sheer Microsoft laziness, or is there something Im just not getting?
-
Do other programming frameworks / other OSes have similar problems or is it just a Windows thing?
-
Is there any way around it other than changing every function in our app?
This is a limitation of the underlying Windows user interface and has little to do with the .NET framework itself. Performing many actions on controls and windows (in the Windows sense, not the component model sense) requires that the actions be performed on the thread that created the window handle. The .NET framework is like any other application and must abide by this rule.
Certainly, Microsoft could have put syncronization in the framework to prevent this problem, but doing so would have added a great deal of performance overhead for applications that do not need that functionality (because they’re largely single threaded).
Microsoft’s decision is to force those that need the overhead to manage it explicitly rather than forcing it on everyone.