Reason for .Net UI Element Thread-restriction
- by Charles Bretana
We know that it is not possible to execute code that manipulates the properties of any UI element from any thread other than the thread the element was instantiated on... My question is why?
I remember that when we used COM user interface elements, (in COM/VB6 days), that all UI elements were created using COM classes and co-classes that stored their resources using a memory model referred to as Thread-Local-Storage (TLS) , but as I recall, this was required because of something relaetd to the way COM components were constructed, and should not be relevant to .Net UI elements. Wha's the underlying reason why this restriction still exists? Is it because the underlying Operating System still uses COM-based Win32 API classes for all UI elements, even the ones manipulated in a managed .Net application ??