Denis Gladkikh

outcoldman

My personal blog about software development

  • 20 Dec 2009
  • .NET, .NET 4.0, WPF, WPF 4, Visual Studio 2010
  • 0 comments

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

WPF Toolkit теперь в .NET Framework 4.0

В статье What's New in WPF Version 4 (MSDN) на MSDN приводится выражение new controls, но мы-то с вами знаем, что никакие они не новые, а это те контролы, которые раньше были в составе WPF Toolkit: DataGrid, Calendar и DatePicker, а так же полезный класс VisualStateManager. При переходе с проекта на .NET 3.5 на .NET 4.0, если использовали контролы из WPFToolkit, то единственное, что нужно – это убрать зависимости на старые библиотеки Toolkit, и убрать объявления namespace’ов контролов из tookit’a. Когда эти контролы были в составе WPFToolkit’a – у них была значительная проблема: не было хорошей и достаточной справки, теперь же все будет и уже есть на MSDN. Кроме того, ScottGu обещает в серии своих статьей (ScottGu - WPF 4 (VS 2010 and .NET 4.0 Series))  выпуск Office Ribbon Control сразу после выпуска WPF 4, как понимаю, включат его опять в состав WPFToolkit.

Удивительно, что на MSDN не приводится информация о том, что DataVisualization для WPF перенесут так же в .NET Framework 4.0, неужели еще не заслужил и останется пока в рамках WPFToolkit? Странно, раз уж переносите контролы, то стоит, наверное, переносить все.

Поддержка Multitouch

По-моему, это просто бесспорно круто. Осталось только подождать пару лет, когда хорошие и дешевые ноутбуки с поддержкой multitouch дотянутся до нашего государства не только для любителей, но и в организации, чтобы действительно можно было начать разрабатывать приложения для них. Если пройтись по некоторым зарубежным фирмам (в основе конечно США), то можно найти уже разработанные решения для ноутбуков с поддержкой Multitouch. Печально еще (смотрел на сайте Lenovo.com), что ноутбуки с Multitouch присутствуют только в комплектации с максимум 14.1 размером монитора. В принципе, для работы понятно, что может больше и не нужно - для производственной: вроде просмотр схем, инженерных чертежей, etc. А вот для программиста, теперь мне кажется, 14 дюймов мало для разработки. С другой стороны Multitouch программисту нужен, наверное, только для того, чтобы разрабатывать для Multitouch, хотя пока не попробуешь – не скажешь точно. Подождем.

Чтобы начать работать с Multitouch нужно ознакомиться с новыми событиями, которые добавили в классы UIElement, UIElement3D и ContentElement, так же следует, наверное, прочитать некоторую литературу, как создавать приложения с поддержкой Multitouch действительно удобными и функциональными, ну и познакомиться с Microsoft Surface SDK.

Windows 7 Shell Intergration

Теперь запросто можно добавлять поддержку всех красивостей и удобностей от Windows 7 в приложение. Для этого нам нужно обратиться к пространству имен System.Windows.Shell и посмотреть, что же он нам предлагает.

Во-первых – это TaskbarItemInfo. Он предлагает управляемую обертку для Taskbar в среде Windows 7. У класса Window появилось свойство (dependency) TaskbarItemInfo, которому и необходимо установить объект типа TaskbarItemInfo (можно как в XAML - декларативно, так и программно). При помощи свойства ThumbnailClipMargin можно установить, какая часть окна будет отображена в Preview окна на taskbar (показывается при наведении, если включено Aero), то есть можно отображать не все окно, а, например, только значимую необходимую часть. Правда не понял, возможно ли вообще отображать какой-то свой шаблон в Preview, который не отображается в окне, такого свойства я не обнаружил, подозреваю, что нужно как-то отображать через спрятанные области. Не удивляйтесь, что когда попробуете использовать TaskbarItemInfo – изменений не увидите на панели Taskbar после запуска под debug из студии, не понял, с чем это связано (скорее всего, с хостящимся процессом от VS для процесса debug), в общем нужно отдельно запускать exe, и тогда все будет работать (может, проблема проявляется только у меня, что-нибудь с Win7 x64 – не знаю, вы, может, скажете?). Более того TaskbarItemInfo позволяет отобразить функциональные клавиши в том же Preview (ThumbButtonInfos), а так же отобразить какой-нибудь свой элемент над иконкой на Taskbar (Overlay), и состояние длительного процесса (ProgressValue и ProgressState). Вот как будет это выглядеть (пример с MSDN)

Untitled8

Другим дополнением является JumpList. Тут все просто, он может в себя включать либо JumpTask, либо JumpPath, первый может задавать программу с набором аргументов, второй путь до файла. Очень удобная вещь для часто выполняемых задач, правда, пользоваться в Windows 7 Jump листами я пока не привык, да и вообще не пользуюсь, потому как нужно еще помнить, что ты открывал последним.

Windows 7 shell integration полезное дополнение, но так как в основном мы все программируем для корпоративных клиентов, то на него нужно смотреть как на возможность дополнения функциональности приложения, если у пользователя стоит Windows 7. Так, если мы как-то отображаем долгий процесс, то почему бы и не отобразить его при помощи TaskbarItemInfo в дополнение: тогда играющий в косынку менеджер всегда сможет заметить, когда программа закончила формировать отчет или выполнила какую либо задачу. Но вот вынести часто используемые файлы просто в JumpList не достаточно, так как мы ограничим пользователей, которые используют более ранние версии Windows, а о них тоже стоит подумать.

Comments