Поток не может получить доступ в ViewModel слое при обновления CanExecute команды
Простая задача: Обновить возможность выполнения кнопки по событию.
Пишу такой элементарный код при помощи MVVM Toolkit:
public partial class MainViewModel : ObservableObject
{
public MainViewModel()
{
_ = Task.Run(async () =>
{
try
{
while (true)
{
await Task.Delay(1000);
CanTest = !CanTest;
}
}
catch (Exception e)
{
Debug.WriteLine(e.Message);
}
});
}
[ObservableProperty]
[NotifyCanExecuteChangedFor(nameof(TestCommand))]
private bool _canTest;
[RelayCommand(CanExecute = nameof(CanTest))]
public void Test()
{
}
}
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
DataContext = new MainViewModel();
}
}
Как видно, тут создается простой класс, который фоном крутит некую задачу, и раз в секунду обновляет состояние bool свойства, по которому идет обновление CanExecute команды.
Для наглядности, что этот код сгенерирует:
public bool CanTest
{
get => _canTest;
set
{
if (!EqualityComparer<bool>.Default.Equals(_canTest, value))
{
OnCanTestChanging(value);
OnCanTestChanging(default, value);
OnPropertyChanging(global::CommunityToolkit.Mvvm.ComponentModel.__Internals.__KnownINotifyPropertyChangingArgs.CanTest);
_canTest = value;
OnCanTestChanged(value);
OnCanTestChanged(default, value);
OnPropertyChanged(global::CommunityToolkit.Mvvm.ComponentModel.__Internals.__KnownINotifyPropertyChangedArgs.CanTest);
TestCommand.NotifyCanExecuteChanged();
}
}
}
public IRelayCommand TestCommand => testCommand ??= new RelayCommand(new Action(Test), () => CanTest);
То есть, самая элементарная реализация INotifyPropertyChanged и ICommand, которая знакома многим.
Теперь суть вопроса:
Этот код приводит к ошибке
Вызывающий поток не может получить доступ к данному объекту, так как владельцем этого объекта является другой поток.
Оно и понятно, мы таском выходим из UI потока, из-за чего мы не можем так просто работать с UI, но как вернуться обратно? У нас есть типичные решения данной проблемы, в которых используется Dispatcher. Ок, допустим, только это ViewModel, отдельный класс, который ничего не знает про UI, мы можем написать костыльно такое
public MainViewModel(Dispatcher dispatcher)
{
_ = Task.Run(async () =>
{
try
{
while (true)
{
await Task.Delay(1000);
dispatcher.BeginInvoke(new Action(() => { CanTest = !CanTest; }));
}
}
catch (Exception e)
{
Debug.WriteLine(e.Message);
}
});
}
и это решит проблему, но только это нарушение MVVM и прочих правил. Используя Dispatcher.CurrentDispatcher мы также избавимся от ошибки, но у нас перестанут обновляться данные, что тоже вроде логично. Собственно, как решить проблему?
А да, само изменение свойства к ошибки не приводит, приводит обновления CanExecute (вызов: TestCommand.NotifyCanExecuteChanged(); ), который генерирует [NotifyCanExecuteChangedFor(nameof(TestCommand))]. Если убрать, обновления в реальном времени у кнопки не будет, но bool свойство значение менять начнет.
P.S. Бесконечный await цикл это для примера, в реальном проекте у меня есть сервис, который отслеживает изменения процесса (запущен или нет), и отсылает событие наружу, это все зарегистрировано в контейнере, из которого и запрашивает ViewModel, где она подписывается и обновляет свойство, получая ошибку.
public class ProcessWatcherService : IProcessWatcher, IDisposable
{
private readonly HashSet<string> _monitoredProcesses = new();
public event EventHandler<ProcessChangedEventArgs>? ProcessChanged;
private readonly ManagementEventWatcher _startWatch;
private readonly ManagementEventWatcher _stopWatch;
private readonly ILogger<ProcessWatcherService> _logger;
public ProcessWatcherService(ILogger<ProcessWatcherService> logger)
{
_logger = logger;
_startWatch = new ManagementEventWatcher(new WqlEventQuery("SELECT * FROM Win32_ProcessStartTrace"));
_startWatch.EventArrived += (_, e) => ProcessChangedEvent(e.NewEvent.Properties["ProcessName"].Value, ProcessStatus.Started);
_startWatch.Start();
_stopWatch = new ManagementEventWatcher(new WqlEventQuery("SELECT * FROM Win32_ProcessStopTrace"));
_stopWatch.EventArrived += (_, e) => ProcessChangedEvent(e.NewEvent.Properties["ProcessName"].Value, ProcessStatus.Stopped);
_stopWatch.Start();
}
public bool Verify(string process)
{
var result = Process.GetProcesses()
?.Any(x => x.ProcessName.ToLower() == Path.GetFileNameWithoutExtension(process).ToLower()) == true;
_logger.LogTrace("Verify process status {process} = {result}", process, result);
return result;
}
public void StartWatch(string process)
{
_logger.LogDebug("Process {process} added to watch list", process);
_monitoredProcesses.Add(process.ToLower());
}
public bool AddAndWatch(string process)
{
StartWatch(process);
return Verify(process);
}
void ProcessChangedEvent(object name, ProcessStatus status)
{
if (name is string processName && _monitoredProcesses.Contains(processName.ToLower()))
{
_logger.LogInformation("Process {process} change status: {status}", processName, status);
ProcessChanged?.Invoke(this, new(processName, status));
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
_startWatch.Stop();
_stopWatch.Stop();
}
}
Ответы (1 шт):
Можно пойти тем же путём, которым реализован например Progress<T>, то есть использовать захват SynchronizationContext.
При этом логически про UI поток знать необязательно. Нужно просто придумать контракт типа "я буду дёргать свойства вьюмодели в том же контексте синхронизации, в котором был создан этот экземпляр вьюмодели". Кстати, само по себе использование контекста синхронизации - кроссплатформенное решение, что является неоспоримым плюсом на фоне использования диспетчера.
public class MainViewModel
{
private readonly SynchronizationContext _context;
public MainViewModel()
{
// захват контекста
_context = SynchronizationContext.Current;
}
}
Здесь рождается ограничение: вьюмодель должна быть создана в UI потоке. Иначе ничего не получится. Ну а дальше просто:
_context.Send(_ => CanTest = !CanTest, null); // ну или _context.Post, если ждать не хочется
(проверить на null контекст только не забыть перед использованием)
И это всё счастье можно завернуть в красивую упаковку с кодогенераторами и добиться чего-то вроде:
[ObservableSynchronizedProperty]
private bool _canTest;
То есть лепить синхронизированные свойства точно так же красиво, как обычные. Здесь нет взаимодействия с View даже под капотом, а следовательно и MVVM в безопасности (хотя в том же WPF UI контекст всё прекрасно знает про диспетчера и нагло на его основе работает).