ko444evnik (ko444evnik) wrote,
ko444evnik
ko444evnik

Опыт изучения WPF.

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

Осваивалась тема первоначально по этим источникам:

1) Петцольд "Windows Presentation Foundtation. Базовый курс." (950 стр)
2007 - оригинальное издание; 2008 - перевод.
2) МакДональд "Windows Presentation Foundtation 3.0 для профессионалов" (980 стр)
2007 - оригинальное издание; 2008 - перевод.
3) MSDN - тут уж лес кромешный без конца и края. тут не знаешь куда зайдешь, не знаешь откуда выйдешь, не знаешь мимо чего прошел и оставил неосмотренным.
4) статьи из MSDN Magazine - оказалось гораздо полезнее. хотя бы для того чтобы заранее сориентироваться, что вызывает проблемы.

МакДональд был куплен первым - но где то с год бестолково валялся. просто потому, что стиль обучения "открыть любую страницу - прочитать/усвоить - по упоминаниям/ссылкам перейти к связанной теме - повторять до тех пор пока не кончатся страницы" не срабатывал. по отдельным кусочкам материал не усваивался. т.е. текст вроде читался и осознавался, но вот понимания "как вот это вот" связано с "вот тем" не возникало.

пришлось дополнительно прикупить Петцольда - переключиться на режим "парового катка" - и продвигаться вперед последовательно и обстоятельно а главное - в тылу живых врагов не оставлять.

с августа 2009 примерно по февраль 2010 - если выдавалось время - по главе в день читался сначала П, потом МД, а между ними вперемежку - MSDN...

Петцольд - прекрасный методист, но есть нюанс - процесс обучения рассчитан на тех кто работал в стеке Дельфи/С++Builder/C# WinForms. соответсвенно 18 первых глав разжевывается как C#-кодом реализовать то, что в реальном применении практически всегда будет декларативно определяться хамлом (ХАМЛ впервые появляется в 19 главе (из 31)). с одной стороны - понимание "закулис" полезно, с другой - "лишняя работа". какие то вещи (типа Arrange/Measure) требовали много усилий для понимания, но в реальной жизни - никогда не применялись.

МакДональд - шел "вторым номером" - как "эссе по теме" для закрепления материала. плюс у него по тексту были разбросаны разнообразные полезные ссылки на внешние ресурсы.

Что было необычно (или наоборот - обычно) по сравнению с WinForms:

1) разделение обязанностей между классами Application и Window(и Page). концепции MDI здесь нет - все окна равноправны;
2) следует отвыкнуть от пиксельного мышления. необходимые размеры определяются в единицах DPI, да и это очень быстро перестает быть хоть сколько нибудь важной проблемой;
3) отвыкнуть (по крайней мере на этапе обучения) от необходимости создавать собственные классы UI-элементов. 99% желаний и возможностей покрывается просто определением стилей (Style) и применением (если надо - и допилкой) шаблонов (Template). наледовать и создавать собственные компоненты тоже можно - и легко. просто чаще всего - не нужно;
4) бОльшая часть длительных и асинхронных операций - как и прежде - с успехом делается через старый класс BackgroundWorker.

Суть поста - список тем-"матрешек". Чтобы заставить WPF работать - требуется понять взамодействие между собой их всех - сразу и в совокупности.

Концепции компоновки и содержимого UI-элементов:
1.1) различие ContentControl и ItemsControl
(!) полезным оказалось сразу усечь роль ScrollViewer и декораторов Border/Viewbox

1.2) дуальность дерева UI-элементов - следует различать Логическое Дерево и Визуальное Дерево (см. возможности VisualTreeHelper и LogicalTreeHelper); "айсберг" во всех смыслах (скажем, если поскрести обычный элемент Button - обнаружится целая матрешка нанизанных друг на друга компонентов. ).

1.3) Панели
(!) тесно связаны с концепцией AttachedProperties (Присоединенных Свойств) - невозможно использовать без их понимания;
(!) мои потребности долгое время покрывались сочетанием Grid+GridSplitter+StackPanel и Canvas;

далее:

2. концепция Ресурсов - по сравнению с WinForms - очень хороша. определение ресурсов как правило полностью делается в декларативной Хамл-разметке. теснейшим образом связана c концепцией дерева элементов. усечь различие StaticResource/DynamicResource ("банальное предположение" что StaticResource "не изменяется", а DynamicResource "изменяется" -неверно ). усечь концепцию включения внешнего хамл-файла через MergedDictionary (вот она, ИМХО, могла бы быть чуток попрямее).

3. DependencyProperty (Зависимые Свойства) и примкнувшие AttachedProperties (Присоединенные Свойства). опять же - теснейшим образом связаны c концепцией дерева элементов. мощная и удобная (после освоения :) ) вещь, но "воплощенный айсберг". в принципе все просто - и суть словами объясняется за пару минут. но есть и нюансы. и побочные эффекты. мой собственный кодогенератор собирает ее из 5-7 отдельных деталек.

4. МаршрутизируемыеСобытия. Маршрутизируемые собственно по тому самому дереву элементов ( тут с ходу могу припомнить граблю с PreviewExecute ).

5. МаршрутизируемыеКоманды. основаны на МаршрутизируемыхСобытиях.
(!) RoutedCommand и RoutedUICommand - "тоже айсберг". деталек штук 8. есть и грабли и дыры. но в целом - достаточно юзабельно.
(!) актуальны для более-менее статичного содержимого (т.е. сценарий: как все элементы определены в хамле - так с ними и работаем). если душа сразу хочет динамического создания UI-элементов - рекомендуется смотреть что такое шаблон MVVM и каковы особенности создания команд там.

6. СтилиЭлементов (Style), ШаблоныЭлементов( ControlTemplate, ItemsPanelTemplate ) и их взаимодействия и расширения. в особенности - Триггеры(Trigger) - на них основана вся ui-элементная-анимация.

7. ПривязкаДанных (см Binding, BindingExpression, IValueConverter, IMultiValueConverter). вещь необходимая и мощная (гораздо мощнее аналога в WinForms). но имеются и некоторые "особенности".

8. ШаблоныДанных (DataTemplate и HierarchialDataTemplate). необходимы для списочно-древовидных элементов и прочего. Бакалейшик и Кардинал ListBox c правильно навешанными шаблонами - это сила!

Кроме того имеется весьма полезная (и при этом простая) штука под названием Markup Extension (Расширения хамл-Разметки), которая по книгам не проходила. и наткнулся на которую я уже сильно случайно и опосля.

Что касается всякой 2D/3D графики - для начала следует знать только то, что любой паршивый Shape (кружочек, линия, полигончик и т.п.) является полноценным UI-элементом и все вышеперечисленнные и концепции действительны и для них.

P.S.
Неожиданные находки по ходу обучения, которые лично мне пришлись по душе:
- FlowDocument ( + Annotation )
- AdornedLayer
- InkCanvas

разочарования:
- RichTextBox. воплощенная диверсия. потенциально хороший, но с одной стороны безжалостно обкорнатый, а с другой - безбожно зафлуженный мусором элемент. пользуюсь практически исключительно TextBox-ом.
- TreeView кривоват. т.е. добится нужных реакций от него можно, но только не сходу и не без бубна.
- общая производительность композитных элементов. практически достижимый предел UI-элементов ~10000 штук. вопрос хорошо исследован Петцольдом http://msdn.microsoft.com/ru-ru/magazine/dd483292.aspx
Tags: .net, .wpf, графика
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 3 comments