Комментарии 17
НЛО прилетело и опубликовало эту надпись здесь
Да, спасибо, дельное замечание.
я например обычно Exception возвращаю, а вот зачем другие варианты Вы назвали, можете подробней обьяснить?
Хоть я таким способом ещё не пользовался, но попробую ответить:
UnsetValue — значение-метка, используемое в сценариях, когда системе свойств WPF не удается определять запрошенное значение DependencyProperty. UnsetValue используется вместо Nothing, так как Nothing может быть допустимым значением свойства, так же как и допустимое (и часто используемое) DefaultValue.
UnsetValue — значение-метка, используемое в сценариях, когда системе свойств WPF не удается определять запрошенное значение DependencyProperty. UnsetValue используется вместо Nothing, так как Nothing может быть допустимым значением свойства, так же как и допустимое (и часто используемое) DefaultValue.
НЛО прилетело и опубликовало эту надпись здесь
а зачем по две пустые строки после каждой строчки кода?
Насколько я понимаю достаточно просто вернуть себя из функции ProvideValue, поскольку объект одновременно является и конвертером и уже создан. Так зачем же создавать ещё один? Пользуюсь этой системой уже давно. Пока проблем не заметил.
Кстати, в таком варианте можно добавлять к Конвертеру кучу параметров и инициализировать их прямо в месте создания и для каждого места разные.
Например:
Параметры конечно только для примера, но иногда нужно определить более одного параметра и ConverterParameter с этим не справляется
public override object ProvideValue(IServiceProvider serviceProvider){
return this;
}Кстати, в таком варианте можно добавлять к Конвертеру кучу параметров и инициализировать их прямо в месте создания и для каждого места разные.
Например:
<Label Content="{Binding Path=Date, Converter={converters:DateConverter Format=ShortString, Calendar=Gregorian}}" />
public class DateTimeToString : ...
{
public override object Convert(...){...}
public string Format{get;set;}
public CalendarType Calendar{get;set;}
}
Параметры конечно только для примера, но иногда нужно определить более одного параметра и ConverterParameter с этим не справляется
«Насколько я понимаю достаточно просто вернуть себя из функции ProvideValue, поскольку объект одновременно является и конвертером и уже создан. Так зачем же создавать ещё один? „
А и правда, зачем. Видимо, это избыточно…
“ но иногда нужно определить более одного параметра и ConverterParameter с этим не справляется»
О, спасибо большое, это действительно классный способ!
Если вы не возражаете, я дополню вашим кодом статью.
А и правда, зачем. Видимо, это избыточно…
“ но иногда нужно определить более одного параметра и ConverterParameter с этим не справляется»
О, спасибо большое, это действительно классный способ!
Если вы не возражаете, я дополню вашим кодом статью.
Конечно можно.
В принципе есть некоторое преимущество в использовании статического конвертера. Например, если вам нужно создать дата темплейт, включающий конвертер и использовать его для длинного списка элементов в ItemsControl. Тогда новый экземпляр конвертера будет создан, а главное прикреплен к каждому Item. Если же используется статический элемент, то будет создан и тут же уничтожен конвертер как MarkupExtension, а привязанный надолго статический конвертер останется в одном экземпляре. Жаль что тогда теряется возможность использования параметров. Или просто при таком использовании нужно просто воспользоваться старым способом с ресурсами и тогда единичный экземпляр конвертера будет создан как ресурс, а в качестве временного MarkupExtension будет выступать StaticResource. По поводу DynamicResource не уверен, что он сам не зависает в памяти надолго. Я бы использовал ваш вариант для конвертера без параметров и мой для конвертера с параметрами.
В принципе есть некоторое преимущество в использовании статического конвертера. Например, если вам нужно создать дата темплейт, включающий конвертер и использовать его для длинного списка элементов в ItemsControl. Тогда новый экземпляр конвертера будет создан, а главное прикреплен к каждому Item. Если же используется статический элемент, то будет создан и тут же уничтожен конвертер как MarkupExtension, а привязанный надолго статический конвертер останется в одном экземпляре. Жаль что тогда теряется возможность использования параметров. Или просто при таком использовании нужно просто воспользоваться старым способом с ресурсами и тогда единичный экземпляр конвертера будет создан как ресурс, а в качестве временного MarkupExtension будет выступать StaticResource. По поводу DynamicResource не уверен, что он сам не зависает в памяти надолго. Я бы использовал ваш вариант для конвертера без параметров и мой для конвертера с параметрами.
Не просто можно вернуть себя из функции ProvideValue, но и нужно, т.к. в противном случае значения дополнительных параметров не будут проинициализированы, т.к. создаётся новый экземпляр конвертора.
И да, огромный респект автору за статью!
И да, огромный респект автору за статью!
Что ещё хуже, подобное использование приводит к тому, что при каждом использовании конвертера пораждается новый экземпляр, что может сильно увеличить количество потребляемой памяти.
А разве если использовать StaticResource не используется тот же самый объект?
За метод огромное спасибо! Надоело постоянно ресурсы создавать, а то что предложил urrri это вообще праздник какой-то ))
Пример забавный. Но именно такую задачу, я бы решал вот так:
<TextBlock Text="{Binding Path=Date,StringFormat={}{0:d}}" />
Да, в этом автор статьи погорячился. Используется один и тот же объект. Отключается это с помощью аттрибута x:Shared=«false». По умолчанию это значение = true.
Статья интересная, спасибо, возможно будем использовать подобный подход в своих проектах.
Статья интересная, спасибо, возможно будем использовать подобный подход в своих проектах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WPF: конвертеры как MarkupExtension