Асинхронное обновление состояния команды

xellan24rus, скорее всего порядок "обновления" на это влияет. Потому что не раз сталкивался немного с другой вещью: есть свойство в VM, оно же используется в качестве CanExecuted в некой команде. Но! Если привязать элемент View IsEnabled к тому свойству напрямую - все замечательно. А вот, если этот элемент ведется от этого же свойства, но от команды - он "енаблируется" только по тычку мыши по окну! Хотя все возможные дебаги показывают что это свойство давно уже в TRUE. Не стал сильно разбираться, переделал, но пока такой вот "факт" остался непонятным явлением...

Добавлено через 3 минуты
Иными словами, происходит некая "серия команд", часть из которых не достигает получателей (типа застревает), но если тыкнуть окно - все приходит. Что интересно - точно с таким же проектом на таких же условиях все работает. Вообще не понял что происходит с этим, каждую запятую проверял - ну блин вообще отличий нет. Но не работает. Чудеса.

0

Сообщение от wizard41 Сейчас приделаю это.

с Task.Run я ранее код кидал там работало четко все от свойства

Добавлено через 2 минуты
wizard41, а если сделать локальный сервер для активации и деактивации Enable? Допустим даже фокуса у окна не будет и клика. Только в реальном времени должен обновить свойство локальный сервер. Такая симуляция подойдет под ваш вопрос? Можно HttpListern сделать чтобы не заморачиваться так сильно

0

Сообщение от xellan24rus Такая симуляция подойдет под ваш вопрос?

Да, конечно это будет самое то. Сейчас попробую с Task.Run сперва

0

Сообщение от wizard41 Сейчас попробую с Task.Run сперва

заберите код с примера что я ранее отправил в смс. Может с ним что то выйдет. Как раз там другой поток + задержка.

Сообщение от wizard41 Да, конечно это будет самое то.

Тогда это идеальная симуляция)

0

Сообщение от xellan24rus а если сделать локальный сервер для активации и деактивации Enable? Допустим даже фокуса у окна не будет и клика.

Это нисколько не будет отличаться от подачи сигнала из другого потока в самом приложении.
Для полной имитации (чтобы исключить фактор фокуса окна) можно создать 3-5 секундный таймер (System.Timers.Timer или System.Threading.Timer).

Я думаю, что ошибка в чём-то ином. И при попытке воспроизведения проблемы, wizard41, вполне возможно, сам найдёт её причину.

0

Элд Хасп, тоже верно. Загвоздка в воспроизведение примера только.

Сообщение от Элд Хасп можно создать 3-5 секундный таймер (System.Timers.Timer или System.Threading.Timer).

А если свернуть приложение и там пробовать с сервера работать с Enable? тогда фокуса не будет.

0

Сообщение от xellan24rus тогда фокуса не будет.

Достаточно выбрать другое окно. А кнопка должна продолжать мигать Enabled-Disabled

0

Залил клавиатуру, пришлось разбирать/стирать/сушить...
xellan24rus, попробовал ваш EnabledCommandAsync() - результат тот же:

Кнопка что активится от Команды - не активируется. Ну и это как бы предполагается, т.к. проблема не в источнике сигнала, а в самой команде... Что-то вокруг этого крутится.

0

0

Приложил проект, если будет время натурально посмотреть что происходит.

Вложения

WpfApp_TestCommandIncp.7z (16.1 Кб, 10 просмотров)

0

Сообщение от Элд Хасп Это нисколько не будет отличаться от подачи сигнала из другого потока в самом приложении

Да, потому что сигнал от реального устройства тоже фактически из другого потока прилетает. А окну какая разница что в самом потоке происходит и в каком.
Поэтому Async Task полностью эмулирует ситуацию.

Добавлено через 11 минут
Надо попробовать какую-то другую базовую реализацию ICommand. Считаю, что неправильно работает моя текущая реализация, хотя она вполне себе "стандартная" - как у всех.
Раньше этот момент "замаскировывался" тем, что все команды приходили от элементов самого окна и такая ситуация была не видна. Но как только источник команды стал "сторонним" - вылезли такие странные вещи.

0

Сообщение от wizard41 Надо попробовать какую-то другую базовую реализацию ICommand.

Попробуйте эту.
Простые реализации для тем на форуме

Добавлено через 4 минуты

Сообщение от wizard41 Приложил проект C# 38 39 40 41         public void RaiseCanExecuteChanged()         {             CanExecuteChanged?.Invoke(this, EventArgs.Empty);         }

Здесь должен быть переход в UI поток.

0

Сообщение от Элд Хасп Попробуйте эту.

Ага, завтра буду пробовать, крутить-вертеть... Надо понять что тут не так.

0

C# 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28     internal class AsyncRelayCommand : ICommand     {         private readonly Func<Task> _execute;         private readonly Func<bool> _canExecute;           public event EventHandler CanExecuteChanged;           public AsyncRelayCommand(Func<Task> execute, Func<bool> canExecute = null)         {             _execute = execute;             _canExecute = canExecute;         }           public bool CanExecute(object parameter)         {             return _canExecute == null || _canExecute();         }           public async void Execute(object parameter)         {             await _execute();         }

Смысл этой реализации, вообще, ускользает от меня.
"А чтобы было!" - наверное?

Добавлено через 2 минуты
Вот здесь есть ссылка на более-менее нормальную реализацию асинхронных команд: Интерфейс и асинхронность

Добавлено через 1 минуту
А ваша реализации по сути ничего не упрощает при применении, только добавляет ещё один лишний тип.

Добавлено через 2 минуты

C# 6 7 8 9 10 11 12 13 14 15 16     internal abstract class BaseCommand : ICommand     {         public event EventHandler CanExecuteChanged         {             add { CommandManager.RequerySuggested += value; }             remove { CommandManager.RequerySuggested -= value; }         }           public abstract bool CanExecute(object parameter);         public abstract void Execute(object parameter);     }

Какая-то гибридно мутантная реализация.
Для UWP - не подойдёт так как есть CommandManager.
Для WPF не подойдёт так как нет публичного метода поднятия CanExecuteChanged.

1

Сообщение от Элд Хасп Смысл этой реализации, вообще, ускользает от меня.

Это только сегодня появилось - AsyncRelayCommand предложил xellan24rus...

0

Элд Хасп, в общем, потыкался с разными вариантами RelayCommand - пока ситуация остается прежней.

Почему это работало в первой версии:
Рассмотрел детально первый проект, где все команды и их CanExecute отрабатывали четко - оказалось, там я контролировал флаг ComConnection, который просто отвечает за факт соединения с COM-портом, а это происходит почти моментально.
Проблема появилась именно тогда, когда я стал проверять ответ от устройства - а он, само собой, приходит не сразу а с некоторой задержкой. Вот тут то все и поломалось.

Почему это работает для другого устройства по USB:
Тут почти точно так же, как описано выше - устройство USB либо есть, либо его нет. И если оно есть, то подключение к нему происходит мгновенно, что сразу же отражается на свойстве в команде и она работает правильно (активирует canexecute).

От сюда возникает вывод, что причина кроется в "запоздалых" изменениях свойств, которые, почему-то, уже не отслеживаются CanExecute'ами команд. Это подтвердилось и в последнем экспериментальном проекте с async Task: если в ней у Task.Delay(300) задержку выставить 0, то все будет работать как надо. В других случаях, получается, что эту команду нужно каким-то образом "пнуть", чтобы она обновила у себя canexecute. Это и происходит при любой другой активности окна.

Странно еще то, что такая проблема ни где не освещена прежде, как-будто с ней никто не сталкивался. Хотя, вряд-ли ситуация с изменением свойств через некоторое время после первичной активности вызывающей событие команды, и/или из других потоков является каким-то неординарным явлением...

Поэтому, в настоящий момент, единственным работающим вариантом остается прямая привязка IsEnabled контрола к нужному свойству. Это работает безотказно при любых задержках и из любых потоков.

0

Сообщение от wizard41 пока ситуация остается прежней.

"Потыкайте" здесь: WpfApp_TestCommandIncp-EldHasp.7z

Основная часть устранения причины:

1

Элд Хасп, ну да, ну да. Интуитивно предполагал, что нужно как-то RaiseCanExecuteChanged() использовать, но видно к чему это привело: создание еще одного кастомного INCP вместе RelayCommand )

Добавлено через 2 минуты
Полагаю, что создавать зависимости нужно только для таких "трудных" команд разнесенных по времени. Для обычных оконных - использовать простой подход, как и прежде.

0

Сообщение от wizard41 Полагаю, что создавать зависимости нужно только для таких "трудных" команд разнесенных по времени. Для обычных оконных - использовать простой подход, как и прежде.

Так как в VM не должно быть зависимости от View, то и "оконных команд" тоже не должно быть.

VM зависит от Модели.
В данном случае, ваша Модель - это Device Device1.
А события Модели НУЖНО прослушивать иначе не удастся реализовать актуальное её отражение в свойствах VM.

Добавлено через 4 минуты
Для UWP этого не нужно.
Там используется какой-то иной способ ревалидации команд. Возможно, там просто по какому-то таймеру проверяются все команды в GUI - точно не знаю.

0

Сообщение от Элд Хасп Так как в VM не должно быть зависимости от View, то и "оконных команд" тоже не должно быть.

Я имел в виду команды, которые отправляются непосредственно из интерфейса приложения (кнопки), которые и отрабатывают тут же. Зачем для них создавать дополнительные зависимости, если они сами по себе извещают всех.
Проблема возникала с теми командами, canexecute которых зависел от "внешнего мира".

Добавлено через 3 минуты
Команда - это же View-компонент? Поэтому размещать их в VM самое место. Видел что некоторые пихают команды в Модели, что мне кажется вообще не верным. Т.к. модели могут использоваться не только в UI-приложениях.

0

Сообщение от wizard41 Зачем для них создавать дополнительные зависимости, если они сами по себе извещают всех.

Если бы было так просто....
Команда "сама по себе" никого не извещает.
Этим занимается CommandManager. Но многие разработчики считают его использование отрицательным фактором. Поэтому есть пакеты в которых реализация команд не имеет автоматической подписки на CommandManager.RequerySuggested и в таких пакетах всегда явно надо подымать CanExecuteChanged.
Не помню точно, но в каком-то "большом" есть такая реализация. Может быть в ReactiveUI.

Добавлено через 1 минуту

Сообщение от wizard41 Команда - это же View-компонент?

С какого перепуга?
ICommand находится в сборке System.ObjectModel.dll. Эта сборка общего применения, входит даже в Standard 2.0.

0