Я считаю, что параметры команды WPF являются ограничением. Возможно, это признак того, что я использую их не по назначению, но я все еще пытаюсь, прежде чем отказаться от них и выбрать другой подход.
Я собрал систему для асинхронное выполнение команд, но сложно использовать что-либо, требующее ввода данных. Я знаю, что один общий шаблон с командами WPF - передать this. Но this вообще не будет работать с асинхронными командами, потому что тогда все свойства зависимостей будут недоступны.
Я получаю такой код:
<Button Command = "{Binding ElementName=servicePage, Path=InstallServiceCommand}">
<Button.CommandParameter>
<MultiBinding Converter = "{StaticResource InstallServiceParameterConverter}">
<MultiBinding.Bindings>
<Binding ElementName = "servicePage" Path = "IsInstalled"/>
<Binding ElementName = "localURI" Path = "Text"/>
<Binding ElementName = "meshURI" Path = "Text"/>
<Binding ElementName = "registerWithMesh" Path = "IsChecked"/>
</MultiBinding.Bindings>
</MultiBinding>
</Button.CommandParameter>
</Button>
а также нужен класс InstallServiceParametersConverter (плюс InstallServiceParameters).
Кто-нибудь видит очевидный способ улучшить это?





Вам нужно что-то, что позволит вам запросить нужный объект. Возможно, вам нужен объект только для хранения этих параметров, которые родительский объект может предоставить как свойство.
На самом деле вам следует оставить команды синхронными и выполнять их асинхронно, отбрасывая новый поток или передавая их диспетчеру команд (начальный этап).
Я не уверен, что считаю улучшением дублирование кода CanExecute и обработки исключений в каждой создаваемой мной команде. Спасибо хоть.
Позвольте мне указать вам на мой проект с открытым исходным кодом Caliburn. Вы можете найти его на здесь. Функция, которая в наибольшей степени поможет решить вашу проблему, кратко задокументирована здесь
Прошло некоторое время, но я не думаю, что вы не возражаете расширить это за рамки ответа только по ссылке?
Команды предназначены для того, чтобы избежать тесной связи между вашим пользовательским интерфейсом и логикой программы. Здесь вы пытаетесь обойти это, поэтому вам будет больно. Вы хотите, чтобы ваш пользовательский интерфейс был привязан к какому-либо другому объекту (который содержит эти данные), и тогда ваша команда может просто вызвать этот объект. Попробуйте поискать MV-V-M или посмотрите пример PRISM.
Сначала ваше предложение звучало как очень хорошая идея, но затем я понял, что, хотя это очень хорошее предложение для синхронных команд, передавать общий (глобальный) объект асинхронному методу - плохая идея, потому что это может изменить промежуточное выполнение. .
Попробуйте использовать что-то вроде MVVM:
Создайте класс, в котором хранятся все данные, отображаемые в текущем «представлении» (окно, страница, все, что имеет смысл для вашего приложения).
Привяжите свой элемент управления к экземпляру этого класса.
Пусть класс предоставит некоторые свойства ICommand, свяжите свойство Command кнопки с соответствующим свойством в классе данных, вам не нужно устанавливать параметр команды, потому что все данные уже были переданы объекту с использованием обычной повседневной привязки данных.
У вас есть производный класс ICommand, который обращается к вашему объекту, посмотрите на эту ссылку для нескольких реализаций:
http://dotnet.org.za/rudi/archive/2009/03/05/the-power-of-icommand.aspx
Внутри метода, вызываемого командой, упакуйте все необходимые данные и отправьте их в фоновый поток.
Я не понимаю, почему это проблема. Я использовал WPF вот так, сколько себя помню. Это также означает, что вы можете повторно использовать конвертер с разными источниками данных в любое время и не привязаны к типу
this. Можете ли вы пояснить, почему вы считаете, что это неправильно?