After opening a form in a new thread you may notice that it doesn't follow the Look and Feel settings of your main application form. The reason for this is that each thread possesses its own DefaultLookAndFeel instance, for it is marked with the ThreadStatic attribute in our code. Knowing this fact leads to the necessity of synchronizing DefaultLookAndFeel instances from different threads. This example demonstrates a possible solution of synchronizing Look and Feel settings in threaded forms.
Question Comments
Added By: Peter Boogaard at: 8/23/2014 1:44:59 PM
This is an interesting topic, which should probably be explained more thoroughly in the "normal" documentation. We converted our application to adopt the DevExpress skinning, but we have dozens of threads and hundreds of forms and messages. Some messages will just not show up in the correct skin, which is driving us crazy. They must have been generated from a non-UI thread. But in a large app it's not so easy to keep every thread synced on the look and feel.
If the DefaultLookAndFeel would have been static for the application rather than per thread this would have prevented so many headaches (for many users if I go through the many threads on this).
So my question is: Why? Why is the ThreadStatic attribute applied, what advantage does this give over all disadvantages that makes it worth it? You did not chose the same solution for the default font, then why for the default look and feel?