The Windows Community Toolkit is a collection of helpers, extensions, and custom controls. It simplifies and demonstrates common developer tasks building .NET apps with UWP and the Windows App SDK / WinUI 3 for Windows 10 and Windows 11. The toolkit is part of the .NET Foundation.
Most GUI frameworks are single-threaded, requiring you to manually marshal/dispatch the PropertyChanged events to the UI thread. I've been searching for an automated solution for this over the past few days, and it's been quite challenging because:
ViewModels should be independent of the UI, so manually handling the marshalling in the ViewModels is not ideal.
Modifying the GUI frameworks to include auto-dispatching isn't feasible (1: too much effort, 2: there's probably a reason they haven't done it automatically).
My Attempts to Solve It
I considered creating an intermediate layer between the ViewModel and the GUI framework. I experimented with source generators, but I didn't achieve significant results (e.g., passing the generated code to the GUI framework while using the original object elsewhere).
Overriding the OnPropertyChanged function to dispatch all event handlers to the UI thread didn't seem practical either, as some event listeners might not need to be on the UI thread.
I thought about monitoring from which synchronization context the event handlers are registered. If they are registered from a specific synchronization context, we could ensure the event handler is dispatched to it. This way, if an event is raised from a non-UI thread, only necessary event handlers would stress the UI thread, while others would not be unnecessarily dispatched. However, this isn't feasible because we can't override the PropertyChangedEvent add accessor to save the synchronization contexts!!!!!!.
Of course, this approach makes ViewModels not raw POCO objects, but I think this is the nearest solution, except for the intermediate layer and GUI framework modifications, which both seem impossible to me.
(And i wanted the feature request in the .NET CommunityToolkit not Windows specific CommunityToolkit but the feature request links navigated me there. :( )
Considering Making PropertyChanged Events Virtual
Why It Might Be a Good Idea
Most GUI frameworks are single-threaded, requiring you to manually marshal/dispatch the
PropertyChangedevents to the UI thread. I've been searching for an automated solution for this over the past few days, and it's been quite challenging because:ViewModels should be independent of the UI, so manually handling the marshalling in the ViewModels is not ideal.
Modifying the GUI frameworks to include auto-dispatching isn't feasible (1: too much effort, 2: there's probably a reason they haven't done it automatically).
My Attempts to Solve It
I considered creating an intermediate layer between the ViewModel and the GUI framework. I experimented with source generators, but I didn't achieve significant results (e.g., passing the generated code to the GUI framework while using the original object elsewhere).
Overriding the
OnPropertyChangedfunction to dispatch all event handlers to the UI thread didn't seem practical either, as some event listeners might not need to be on the UI thread.I thought about monitoring from which synchronization context the event handlers are registered. If they are registered from a specific synchronization context, we could ensure the event handler is dispatched to it. This way, if an event is raised from a non-UI thread, only necessary event handlers would stress the UI thread, while others would not be unnecessarily dispatched. However, this isn't feasible because we can't override the PropertyChangedEvent add accessor to save the synchronization contexts!!!!!!.
Of course, this approach makes ViewModels not raw POCO objects, but I think this is the nearest solution, except for the intermediate layer and GUI framework modifications, which both seem impossible to me.
(And i wanted the feature request in the .NET CommunityToolkit not Windows specific CommunityToolkit but the feature request links navigated me there. :( )