по умолчанию она задисаблема ( ProcessingNewPacket = new Command(action, canExecute = () => AllowProcessingNewPacket); ) вычисляемым методом canExecute.
из другого потока вызываю обработчик события
Кнопка должна активироваться, но она все равно серая, и только ткнув в какое-то поле или если окно было не видимо, т.е. ткнув в панели задач
кнопка активируется. при этом по серой кнопке если жамкнуть она естественно отработает.
Может кто знает как это лечится?
Но это капец, конечно! Вообще, Шаблон MVVM сильно переусложнен. Есть опыт Winforms и web(vuejs, svelte).
По ощущениям Winforms была лучшей технологией мс за последние 20 лет.
Вот только яп хилый слишком. нужны минимум макросы времени компиляции(АОП) для избавления от необходимости везде писать Inotify и try\catch\log.
ну рельно вот в свелте, все что в компоненте экспортируется при помощи мета автоматически слушается движком. и зачем так далеко разнесли окно и модель. в итоге вот такой кошмар приходится городить.
Надо глянуть avalonia может там попроще вся эта лабуда работает.
Здравствуйте, takTak, Вы писали:
AA>> CommandManager.InvalidateRequerySuggested();
T>что там у тебя используется? DelegateCommand? взял бы да установил GalaSoft.MvvmLight.CommandWpf.RelayCommand- всё бы и работало без танцев с бубном
самопальный System.Windows.Input.ICommand без излишних наворотов.
спасибо.
Здравствуйте, varenikAA, Вы писали:
AA>на главной форме такая кнопка AA>[code] AA> <StackPanel AA> <Button
AA> Command="{Binding ProcessingNewPacket}"
dispatcher.Invoke(delegate
{
//OnPropertyChanged(nameof(AllowProcessingNewPacket));
ProcessingNewPacket.ChangeCanExecute(); //метод может и по другому зваться в разных реализациях ICommand, важно чтобы он событие СanExecuteChanged вызывал
});
Das Reich der Freiheit beginnt da, wo die Arbeit aufhört. (c) Karl Marx
Здравствуйте, varenikAA, Вы писали:
AA>самопальный System.Windows.Input.ICommand без излишних наворотов.
Т.е. свой самопал работает как надо, и только MVVM во всём виноват
На самом деле, для полного феншуя должны быть две вещи:
* валидатор canExecute
* событие "что-то поменялось, надо перевалидировать canExecute"
Ведь не смущает в winforms, что в случае изменения контента окна надо позвать InvalidateRect или что-то аналогичное дабы насильно вызвать перерисовку? Так и здесь: кнопка отрисована, статус при этом проверили — получили canExecute==false, нарисовали сереньким (или какой там шаблон для disabled-состояния сейчас задан у кнопки). Если после этого что-то поменялось в модели/вьюмодели и выражение canExecute может вычислиться как true, как кнопка про это узнает? Никак.
В уже упомянутом в предыдущих постах RelayCommand всё это есть из коробки, дёргаем метод RaiseCanExecuteChanged — и готово.
Не путай команды WPF, как частную имплементацию, и MVVM, как парадигму.
Команды в WPF действительно не понять что. С одной стороны они понаделали статические ридонли инстансы вроде ApplicationCommandas.Copy, которые понятно как применять. С другой стороны все клепают этот RelayCommand и биндят, и это в принципе херит подход что команда должна нести метаданные и только.
А MVVM хаить.. а есть что лучше? Winforms, кстати, точно также можно прикрутить к MVVM. Просто больше телодвижений.
Здравствуйте, barn_czn, Вы писали:
_>А MVVM хаить.. а есть что лучше? Winforms, кстати, точно также можно прикрутить к MVVM. Просто больше телодвижений.
Не хаю, но лично мне кажется шаблон чрезмерно усложняет взаимодействие модели и окна.
В Winforms обходились обычным Binding практически для всех нужд. и ведь работало.
На крайняк быть может использовать MVP. он многословный, но зато однозначный.
Приемущества MVVM наверно при конвенциальном подходе, когда знаешь все нюансы wpf.
часть работы делается на момент компиляции (Fody -> NotifyProperty).