Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Exception, поскольку ConverterParameter не является наследником DependencyObject'a
Да ну? Пример с эксепшном не приведёте?
ну вот прям чесслово! сами попробуйте прибиндить ConverterParameter куда-нить!
Да, работать не будет, вы правы. Но вы как-то скомкано описали причину. Binding.ConverterParameter — не DependencyProperty, поэтому ему нельзя присвоить Binding, вот и всё.
Смысл ответа, который вы нашли, близок к истине. Создаваемый объект конвертера не наследует DataContext окна. Да и как ему это делать? Мало того, что он не визуальный элемент, так у него даже свойства DataContext нет. :) Где ему искать FirstName и Age?
Поясните, а зачем этот велосипед? Почему бы просто не использовать MultiBinding / IMultiValueConverter?
Также очень актуален вопрос о том, почему все таки без BindingProxy не работает.
Смысл ответа, который вы нашли, близок к истине. Создаваемый объект конвертера не наследует DataContext окна. Да и как ему это делать? Мало того, что он не визуальный элемент, так у него даже свойства DataContext нет. :) Где ему искать FirstName и Age?
Поясните, а зачем этот велосипед? Почему бы просто не использовать MultiBinding / IMultiValueConverter?
Поясните, а зачем этот велосипед? Почему бы просто не использовать MultiBinding / IMultiValueConverter?
По этой же причине хотел вступить в полемику с автором поста, но зашел в его профиль и посмотрел предыдущие записи в блоге… После этого, желание полемизировать отпало…
Ну да, не депендеси. Я по-моему про это и написал.
Я все-таки не считаю это велосипедом. Не знаю, следите ли вы за интервью и выступлениями команды, которая занимается wpf, на 9channel, но и они признают, что wpf нужно развивать также в сторону все более и более легкого, удобного, интуитивно понятного использования конечным пользователем вроде нас с вами. Лично мне ужасно не нравится печатать многа букаф, поэтому вариант с
Кстати, если конвертор унаследовать напрямую от Freezable, то прокси не нужен. И тогда объявление конвертора — в точности такое же, как обычного — где-нибудь в ресурсах, только с использованием лаконичного markup-ex {Binding Name}. Собственно, для меня смысл в этом.
Я все-таки не считаю это велосипедом. Не знаю, следите ли вы за интервью и выступлениями команды, которая занимается wpf, на 9channel, но и они признают, что wpf нужно развивать также в сторону все более и более легкого, удобного, интуитивно понятного использования конечным пользователем вроде нас с вами. Лично мне ужасно не нравится печатать многа букаф, поэтому вариант с
<MultiBinding> <Bindint 1> <Binding 2> ...
Кстати, если конвертор унаследовать напрямую от Freezable, то прокси не нужен. И тогда объявление конвертора — в точности такое же, как обычного — где-нибудь в ресурсах, только с использованием лаконичного markup-ex {Binding Name}. Собственно, для меня смысл в этом.
А не проще запилить именованый инстанс вспомогательного класса и к нему как к ресурсу привязаться. Конвертер же тоже ресурс, он DependencyObject из чисто архитектурных соображений не может быть. Т.е. можно нагородить велосипедов, но зачем?!
В каком смысле — не проще? Не проще в смысле экономии времени? Да, в этом (и только в этом!) смысле — действительно проще. Но ИМХО это засоряет код, что уже само по себе смертный грех. И почему это конвертер не может быть объектом зависимости? Кто именно запрещает? По-моему, это очень логично: конвертору для нормальной работы в условиях реальных задач необходимы вспомогательные параметры; по сути, результат конвертации ЗАВИСИТ от этих параметров, что можно перевести в «конвертор (конкретный экземпляр соотв. класса) зависит от этих параметров». Что еще нужно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BindableConverter для WPF