WPF – это уже далеко не новая технология на рынке, но относительно новая для меня. И, как это часто бывает при изучении чего-то нового, появляется желание/необходимость в изобретении велосипедов с квадратными колесами и литыми дисками для решения некоторых типовых задач.

Одной из таких задач является ограничение ввода пользователем определенных данных. Например, мы хотим, чтобы в некоторое текстовое поле можно было вводить только целочисленные значения, а в другое – дату в определенном формате, а в третье – только числа с плавающей запятой. Конечно, окончательная валидация подобных значений все равно будет происходить во вью-моделях, но подобные ограничения на ввод делают пользовательский интерфейс более дружественным.

В Windows Forms эта задача решалась довольно легко, а когда в распоряжении был тот же TextBox от DevExpress со встроенной возможностью ограничения ввода с помощью регулярных выражений, то все было вообще просто. Примеров решения этой же задачи в WPF довольно много, большинство из которых сводится к одному из двух вариантов: использование наследника класса TextBox или добавление attached property с нужными ограничениями.

Некоторое время назад я писал о том, что хочу сделать небольшой open-source проект Elysium. О проекте в целом вы можете прочитать в приведённой статье, сейчас же стоит упомянуть только то, что одна из частей проекта — тема в стиле Metro для WPF. Дело в том, что вчера я выпустил версию 1.2 (CTP 2) этой темы и сегодня хочу поведать о том, что в ней такого особенного реализовано.

Приветствую вас, дамы и господа!

Весь месяц музыкальный плеер ВКонтакте «Meridian» рос и активно развивался. Были достигнуту хорошие результаты, которыми мы и хотим сейчас с вами поделиться.

Общее представление о том, что такое WPF Layout System, можно получить из msdn (1, 2). Там написано, что элементы управления образуют Visual-дерево, что каждый из элементов управления имеет свой определенный прямоугольник, в рамках которого он отрисовывается, что определение этих прямоугольников возлагается на Layout System и выполняется в 2 этапа (measure и arrange) и что WPF — это retained mode graphic system, в отличие от обычных Immediate и в чем преимущества такого подхода.

Однако при чтении msdn возникает ряд вопросов, на которые в документации ответов нет, и можно только догадываться о том, что происходит. Например — что произойдет, если какой-либо дочерний контрол в measure-стадии запросит для себя размер, превышающий переданный ему availableSize? Или — как при необходимости реализовать методы MeasureOverride и ArrangeOverride правильно, чтобы написанный код не противоречил принятым соглашениям о том, как должны выполняться этапы Measure и Arrange ? Влияет ли результат, полученный на этапе Measure, на этап Arrange и отрисовку, или же на отрисовку влияет только вызов Arrange, а Measure — чисто информационный этап?

Попробуем разобраться более детально в том, что происходит за кулисами.

Вы никогда не задумывались над тем, что навигация в Windows могла бы быть намного удобней? Почему бы не добавить возможность, аналогичную навигации по классам во многих современных IDE, когда в выпадающем списке, вызываемом сочетанием клавиш, отображаются папки с нужным именем, вот так:

Пару месяцев назад мне пришлось реализовывать интерфейс с помощью WPF. В основном использовался FlowDocument, т.к. необходимо было максимально близко организовать UI в стиле веб-страниц.
Привыкший к свободе по позиционированию HTML-элементов с помощью CSS, я не мог найти решение по относительному позиционированию вложенных элементов. Свойства Top, Left, Right, Bottom полностью отсутствуют в плавающих WPF документах. MSDN выдал только класс Figure. Однако HorizontalOffset и VerticalOffset не работают при использовании FlowDocumentScrollViewer. Поиск в гугле также не помог.
Однако решение оказалось более чем простым.