WPF: конвертеры как MarkupExtension

[Seekeer]

Да, спасибо, дельное замечание.

[xander_unlim]

я например обычно Exception возвращаю, а вот зачем другие варианты Вы назвали, можете подробней обьяснить?

[Seekeer]

Хоть я таким способом ещё не пользовался, но попробую ответить:
UnsetValue — значение-метка, используемое в сценариях, когда системе свойств WPF не удается определять запрошенное значение DependencyProperty. UnsetValue используется вместо Nothing, так как Nothing может быть допустимым значением свойства, так же как и допустимое (и часто используемое) DefaultValue.

[Gangsta]

а зачем по две пустые строки после каждой строчки кода?

[f0b0s]

Это не пустые строки, это дурацкие css хабра. Во всех статьях с кодом так. Это отстой. Почему администрация это оставляет, хотя народ постоянно жалуется — загадка.

[justserega]

Можно пользоваться тегом <source lang="cs">

[urrri]

Насколько я понимаю достаточно просто вернуть себя из функции ProvideValue, поскольку объект одновременно является и конвертером и уже создан. Так зачем же создавать ещё один? Пользуюсь этой системой уже давно. Пока проблем не заметил.

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 с этим не справляется

[Seekeer]

«Насколько я понимаю достаточно просто вернуть себя из функции ProvideValue, поскольку объект одновременно является и конвертером и уже создан. Так зачем же создавать ещё один? „
А и правда, зачем. Видимо, это избыточно…

“ но иногда нужно определить более одного параметра и ConverterParameter с этим не справляется»
О, спасибо большое, это действительно классный способ!

Если вы не возражаете, я дополню вашим кодом статью.

[urrri]

Конечно можно.
В принципе есть некоторое преимущество в использовании статического конвертера. Например, если вам нужно создать дата темплейт, включающий конвертер и использовать его для длинного списка элементов в ItemsControl. Тогда новый экземпляр конвертера будет создан, а главное прикреплен к каждому Item. Если же используется статический элемент, то будет создан и тут же уничтожен конвертер как MarkupExtension, а привязанный надолго статический конвертер останется в одном экземпляре. Жаль что тогда теряется возможность использования параметров. Или просто при таком использовании нужно просто воспользоваться старым способом с ресурсами и тогда единичный экземпляр конвертера будет создан как ресурс, а в качестве временного MarkupExtension будет выступать StaticResource. По поводу DynamicResource не уверен, что он сам не зависает в памяти надолго. Я бы использовал ваш вариант для конвертера без параметров и мой для конвертера с параметрами.

[LionSoft]

Не просто можно вернуть себя из функции ProvideValue, но и нужно, т.к. в противном случае значения дополнительных параметров не будут проинициализированы, т.к. создаётся новый экземпляр конвертора.

И да, огромный респект автору за статью!

[justserega]

Что ещё хуже, подобное использование приводит к тому, что при каждом использовании конвертера пораждается новый экземпляр, что может сильно увеличить количество потребляемой памяти.

А разве если использовать StaticResource не используется тот же самый объект?

За метод огромное спасибо! Надоело постоянно ресурсы создавать, а то что предложил urrri это вообще праздник какой-то ))

[Teacher]

Пример забавный. Но именно такую задачу, я бы решал вот так:

<TextBlock Text="{Binding Path=Date,StringFormat={}{0:d}}" />

[Seekeer]

Пример выбран простейших, чтобы не заморачиваться с кодом самой конвертации, статья не про то.

[plsc_Rover]

Да, в этом автор статьи погорячился. Используется один и тот же объект. Отключается это с помощью аттрибута x:Shared=«false». По умолчанию это значение = true.

Статья интересная, спасибо, возможно будем использовать подобный подход в своих проектах.

[Seekeer]

«Используется один и тот же объект. Отключается это с помощью аттрибута x:Shared=«false». По умолчанию это значение = true.»
Да я давно уже с ресурсами не возился, думал по дефолту стоит как раз-таки false.
Спасибо за замечание, вечером отредактирую статью.