Кога WPF решава да поиска отново команди дали могат да се изпълнят?

Кога WPF пита повторно командите дали могат да се изпълняват? Дебъгерът съобщава, че това се случва доста често. Но какъв е точният набор от условия?


command wpf
person Pavel Voronin    schedule 12.12.2012    source източник
comment
Мисля, че зависи от вида на командата. RelayCommand обикновено изисква повторно CanExecuteChanged() по всяко време, когато се промени свойство (мисля, че като стартирате CommandManager.InvalidateRequerySuggested всеки път, когато дадено свойство се промени), докато DelegateCommand не го прави и трябва ръчно да повдигнете CanExecuteChanged, когато дадено свойство разчита на промени. Освен това всички команди се преоценяват, когато са обвързани, така че нещо като скриване и след това показване на прозорец често ще задейства повторно запитване   -  person Rachel    schedule 12.12.2012
comment
Още малко по темата: Как работи CommandManager.RequerySuggested? и Каква е действителната задача на CanExecuteChanged и CommandManager.RequerySuggested   -  person Blachshma    schedule 12.12.2012
comment
Хубава тема по темата тук:robburke. net/2008/04/   -  person Cornel Marian    schedule 24.10.2013
comment
тук има куп обаждания до InvalidateRequerySuggested()   -  person Johan Larsson    schedule 15.12.2014
comment
@CornelMarian работеща връзка: robburke.net/wpf-command- pattern-when-does-it-query-canexecute   -  person g t    schedule 24.05.2019

Отговори (1)


arrow_upward
0
arrow_downward

Версията му за TL; DR е, че методите CanExecute се извикват, когато се появят определени входни събития в прозореца. Има предимно събития с клавиатура и мишка.

Така че всеки път, когато някой щракне или натисне клавиш, ВСИЧКИ команди се анулират от CommandManager (чрез повдигане на CommandManager.RequerySuggested). Това е причината, поради която е важно методите на CanExecute да се поддържат бързи.

Възможно е също така да се справите сами с това, като създадете персонализирана ICommand реализация, която не използва CommandManager за събитието CanExecuteChanged.

person Troels Larsen    schedule 30.03.2015