Расширение, изменение и создание элементов управления на платформе UWP. Часть 1

[Smiz001]

Интересная статься. Тут сам недавно писал валидацию для текст бокса в WPF. А почему вы отказались реализовывать валидацию через ValidationRule?

[MobileDimension]

Спасибо за интересный вопрос! В свое время мы также были им озадачены. Ведь в WPF, как и в его предшественнике Windows Forms, представлены средства валидации. Но путь последующих платформ был тернист и в процессе они что-то теряли и приобретали. Так, в частности, были утрачены коробочные средства валидации: класс ValidationRule, свойства NotifyOnValidationError и ValidationRules у привязок. По этой причине в UWP разработчики вынуждены своими силами валидировать и форматировать введенные данные через события TextChanged или TextChanging

[Smiz001]

Буду знать, спасибо.

[dmitry_dvm]

Спасибо за описание бихевиоров, всё хотел вникнуть, как их самому делать, да подходящего повода не было.
А валидировать мне удобнее через стандартный механизм из Prism https://blogs.msdn.microsoft.com/francischeung/2013/05/07/prism-for-windows-runtime-validating-user-input/
Жду следующую статью. Напишите, пожалуйста, про создание контролов, у которых есть дефолтный шаблон, который можно менять из бленда по Edit a copy.

[MobileDimension]

Мы рады, что материал оказался полезным!
Prism – хорошая библиотека. Просто валидация ввода через присоединенные свойства была по большей части примером, демонстрирующим функциональные возможности и способ применения данного механизма на задаче близкой к читателю.
Следующая часть как раз и будет посвящена теме изменения существующих элементов управления и в частности интересующему вас механизму!

[Milording]

Спасибо большое за статью :)

Хотел узнать, есть ли какая-то существенная разница, если в случае с Behaviors вместо написания своего, использовать EventTriggerBehavior + ControlStoryboardAction?

На мой взгляд, в этом примере нагляднее будет прямо в XAML описать всю логику + Storyboard, чем смотреть в код класса.

[MobileDimension]

Извините, что долго отвечали:) Честно говоря, в своей практике мы предпочитаем описывать собственные поведения внутри кода класса. Поправьте нас, если мы не правы, но в документации мы не обнаружили средств по расширению новых поведений сосбтвенными параметрами. В случае, если таких средств не предусмотрено, то считаем метод, описанный в данной статье более предпочтительным и гибким. Но если такие срадства предусмотены, то выбор способа зависит от индивидуальных предпочтений, либо от код-стайла принятого на проекте.