You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. :( )
The text was updated successfully, but these errors were encountered:
JB0xc390cc
changed the title
[Propertychanged events to be virtual]
[Feature] Propertychanged events to be virtual
Nov 20, 2024
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
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. :( )
The text was updated successfully, but these errors were encountered: