Что вам было трудно понять при изучении WPF

Ответ 1

Извините, это так долго... надеюсь, это полезно! Одна вещь, которую я хотел бы упомянуть, это то, что это понятия/вещи, которые сбивали меня с толку, я не уверен, буду ли я использовать его в качестве подробного списка того, что нужно изучать, если вы только начинаете. Я бы погрузился в некоторые books, прочитал много блогов (Джош Смит, Dr. WPF), и, как правило, погружайтесь и пробуйте все в небольших проектах.

Основные понятия

• Логические и визуальные деревья (ссылки: 1)

  Понимание разных деревьев в WPF. В частности, понимание логического дерева по сравнению с визуальным деревом и как элементы в логическом дереве расширяются в визуальное дерево посредством шаблонов данных, шаблонов управления и т.д.

• Система свойств зависимостей (ссылки: 1, 2)

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

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

  Понимание того, почему это называется свойством зависимости, в этом отношении, заняло у меня некоторое время. То есть, понимая, что ценность свойства исходит из многих разных источников (свойство зависит от этих поставщиков стоимости) и что существует порядок приоритета/алгоритм для того, как устанавливается окончательное значение свойства в любой момент времени.

• Маршрутизированные события (ссылки: 1, 2)

  Понимание того, как они могут пузыряться, маршрутизировать или прятать. Понимая, что вы также можете подключать маршрутизированные события (вместо того, чтобы просто привязывать обработчик событий к событию, которое направило визуальное дерево).

  Советы

  Глава 3 в Adam Nathan WPF Unleashed - это удивительная глава, в которой рассматриваются эти важные новые концепции и которые вы должны прочитать, работать над проектом и затем читать снова.

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

Графические концепции (ссылки: 1)

• Разрешение независимости (ссылки: 1, 2)

  WPF приносит все преимущества независимости resoultion (вы указываете все с автономными пикселями устройства), но это также приводит к некоторым головным болям, которые вам нужно решить. Самое главное, это заставить вещи выглядеть острыми, когда вы хотите, чтобы они воспользовались пиксельной привязкой, установив рекомендации и т.д.

• Сохраненный режим против немедленного режима

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

• Элементы управления, элементы, визуальные объекты (ссылки: 1)

  Понимание того, что каждая вещь в иерархии WPF делает для вас и понимает вес, который он приносит в производительности. В частности, вы используете элемент управления, который вы можете восстановить, восстановить и т.д., Или вам нужно что-то сверхлегкое (например, программирование против визуального уровня), чтобы вы могли жестко и быстро управлять им.

  Советы

  Chris Sells и Ian Griffiths имеют отличное приложение в конце своей книги по программированию WPF, в которой рассказывается о разных типах API WPF, где они вписываются в иерархию и какое значение они приносят.

Шаблоны WPF

• Шаблон Model-View-ViewModel (MVVM) (ссылки: 1)

  Шаблон MVVM уже упоминался как помогающий начать работу с WPF. Я не могу больше согласиться. Вместо того, чтобы заполнять элементы управления данными, вы начинаете преобразовывать данные в визуальные (через шаблоны данных).

• Приведенный шаблон поведения свойства (ссылки: 1, 2, 3)

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

WPF!= Windows Forms

Я знаю, что кто-то уже упомянул об этом, но я хочу решительно согласиться. Есть так много новых и разных концепций, вам действительно нужно отучить немало вещей и подходить к решению проблем с совершенно другого ракурса. В качестве примера, Windows Forms является подсистемой подстановки в режиме реального времени, тогда как WPF является сохраненным режимом (выше).

Много, много способов сделать что-то в WPF

Это забавная вещь, которую нужно воспитывать, но поскольку в WPF так много способов сделать что-то, это почти парализует. Каким образом это правильный способ? Это так? Это оно? Мне пришлось преодолеть страх сделать это неправильно, просто вскочить и учиться на своих ошибках.

Ответ 2

WPF не является WinForms. Большинство, если не все, общих стратегий, которые вы используете для выполнения задач в WinForms, являются неправильным (или наименее эффективным) способом в WPF. Команды, свойства зависимостей, привязка, шаблоны и т.д., Все будет менее полезно, если вы примете мышление WinForms.

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

Переключение на тысячи привязок с преобразователями данных, всего на несколько сотен визуальных элементов, причем данные загружаются и пересчитываются "на лету". Это привело к поправке на улучшение производительности. Было почти немыслимо, что тысячи привязок будут быстрее, чем тысячи предварительно вычисленных визуальных элементов, но это имеет место в WPF.

" Из WinForm в WPF: Краткое справочное руководство" может быть полезно.

Ответ 3

Я бы сказал, что самые трудные моменты, когда я начал изучать WPF, были:

• Стили и шаблоны: мне потребовалось некоторое время, чтобы понять, когда использовать, и как они взаимодействуют друг с другом.
• Сложные привязки с RelativeSource, преобразователями...
• Триггеры: я все еще иногда путаюсь о том, где я должен использовать DataTrigger s, Trigger или EventTrigger s...
• Механизмы свойств зависимостей и приложенных свойств
• Работа маршрутизируемых событий

Есть много мелочей, которые могут показаться трудными сначала, если у вас есть опыт работы с Windows Forms. Вам нужно отучить много вещей и переключиться на совершенно другую ментальную модель структуры пользовательского интерфейса.

Сначала я начал кодировать, как в Windows Forms, с большим количеством кода, но это определенно не так. Шаблон MVVM действительно помог мне войти в философию WPF...

Моим основным источником документации для обучения WPF был, конечно, MSDN, где вы можете найти ответы на большинство ответов, если знаете, как выглядеть. Я также многому научился в следующих блогах:

• Джош Смит в WPF
• JAPF
• Блог Lester WPF
• С# Disciples
• Карл в WPF

Ответ 4

Свойства зависимостей заняли некоторое время. Здесь хорошая статья, и еще один, который помог мне с этой новой концепцией.

Вторая статья содержала следующий абзац, который действительно разъяснил несколько вопросов, которые у меня были.

Ключевое значение Dependency Системой свойств была способность строить свойства, которые автоматически уведомлять зарегистрированную заинтересованную сторону каждый раз, когда значение свойства изменения. Этот свободный, безболезненный и автоматическая реализация шаблон наблюдателя чрезвычайно мощный и значительно снижает бремя для клиентского программиста (в факт, система привязки данных зависит на нем!).

В более общем плане, я также обнаружил, что предварительный опыт работы с веб-разработкой (особенно пользовательский интерфейс браузера) очень полезен для "получения" WPF. Это больше о мышлении, которое он позволяет вам принести в WPF, по сравнению с тем, кто только когда-либо работал с Windows Forms или другими богатыми клиентскими приложениями.

Некоторые более очевидные параллели из веб-мира - это CSS, плавные макеты, анимация jQuery, барботирование/маршрутизация событий и просто удобство с обширными браузерами и объектными моделями DHTML.

Ответ 5

MMVM - довольно сложная вещь, чтобы учиться. Однако я думаю, что это одна из лучших вещей в WPF. Для этого требуется много обучения, потому что у них много сценариев, где это немного сложно реализовать.

Как заметил Томас, там много отличного материала, например, Джоша Смита и других. Будьте осторожны, хотя WPF очень легко изучить, но вы должны использовать его, написав приложение, чтобы увидеть различные сценарии на практике.

Ответ 6

Data Templating (и контроль за темпами).

На первый взгляд, это достаточно просто, но как только вы начинаете пытаться установить привязку между различными файлами XAML, это может серьезно запутать.

Я полагаю, что мне наконец удалось получить приличное понимание через него, просмотрев много документов MSDN, но более того, проб и ошибок. Игра с вещами - это, как правило, лучший способ изучить любую технологию.

Ответ 7

Я все еще не могу указать целевое свойство в анимации без чит-листа:

<DoubleAnimation
Storyboard.TargetProperty=
"(UIElement.RenderTransform).(TransformGroup.Children)[0].(ScaleTransform.ScaleY)" 
To="1.2" Duration="0:0:.2" />

Ответ 8

Позвольте взять его из представления новичков. Я использую простой редактор, такой как KaXML или Sharpdevelop для разработки WPF. и я обнаружил, что я не могу продолжить разработку базы данных без компонента сетки базы данных. Таким образом, он не похож на формы Windows. Начните поиск компонента сети коммерческой базы данных. и в обороне люди скажут, что это не самая трудная вещь или ограничение.

Вы должны работать с файлами С# или другими языковыми файлами, поддерживаемыми .NET Framework для серьезной разработки приложений. Если это не делает это проблематичным, почему мне нужно использовать его на первом месте. Я доволен С#, почему мне нужно использовать WPF?

Самое сложное:

• Связывание данных,
• Зависимость от другого языка (например, С#),
• Возможности графики.

Ответ 9

В WPF макет отличается от http://blogs.msdn.com/b/wpfsldesigner/archive/2010/06/03/layout-techniques-for-windows-forms-developers.aspx для использования редактора макетов

Ответ 10

Самая большая неприятность: вы не можете получить еще одного разработчика для работы над приложением WPF, сделанным профессионалом. Это не относится к WinForms и Asp.net, где любой может работать с очень небольшими проблемами. Это серьезная проблема.

Ответ 11

Различия в синтаксисе привязки были одинаковыми; то есть когда использовать привязку и когда использовать StaticResource/DynamicResource. Когда я впервые изучал WPF, я продолжал смешивать два.

Различные формы DP и прикрепленные свойства также были трудно понять вначале.

Ответ 12

Чтение книг и понимание материала - это одно, а применение их в вашем проекте - другое. Я создавал относительно простой элемент управления списком контактов, как и в Outlook, и сталкивался со многими небольшими, но заметными кривыми обучения.

• Во-первых, Templating кажется простым, поскольку вы читаете, но при игре с ним становится сложнее. Просто установка фонового цвета пользовательского элемента управления, когда текстовое поле становится фокусом, было сложной задачей. Оказалось, что мне пришлось использовать DataTrigger (кто бы мог подумать).
• Использование обёртки в качестве ItemsPanel для окна списка внезапно стало проблемой, поскольку это не было упорядочение элементов (вам нужно поиграть с ним).
• Определенно RelativeSource в привязке.

В основном возможность привязки элементов управления в вашем шаблоне (от родительского к ребенку и наоборот) - хорошая кривая обучения.

Мой совет. Напишите небольшое приложение, и вы увидите, что все будет вместе.