Главная » WPF » Открытое соглашение о пакетах WPF

0

И содержимое, и ресурсы пользуются единым механизмом пакетов. Дополни) тельную информацию о нем дает открытое соглашение о пакетах (Open Packaging Conventions или OPC). В мире COM было понятие о структурированном хранили) ще, для работы с которым был определен ряд интерфейсов (самые важные – IStorage и IStream). В .NET 2.0 не было прямого аналога этой технологии. По сути своей, структурированное хранилище обеспечивало единообразный доступ к структурированной файловой системе. Его интерфейсы могли быть реализованы поверх любой модели упаковки, самой популярной из которых был двоичный фор) мат файла, известный под названием составные файлы  OLE (OLE compound files). Именно этот формат повсеместно применялся в Microsoft Office.

.NET 3.0 включает механизм, являющийся логическим продолжением структу) рированного хранилища и формата составных файлов OLE. Точно так же, как ин) терфейсы IStorage и IStream могли быть реализованы на базе любого формата упаковки, так и в пространстве имен System.IO.Packaging определены интерфей) сы и типы, которые можно применить для доступа к любому формату. И, если сос) тавные файлы OLE являлись эталонной реализацией структурированного храни) лища, то ZipPackage дает эталонную реализацию OPC)пакета (используется алго) ритм сжатия ZIP и метаданные в формате XML).

Об OPC достаточно знать, что это абстрактный способ доступа к структуриро) ванной файловой системе, не зависящий от модели упаковки. Все ссылки на ре) сурсы в WPF – это, по существу, ссылки на части OPC.

В модели OPC можно выделить три основных концепции: пакет, часть и связь. Один пакет состоит из нескольких частей, между которыми имеются связи. Связи закодированы в части со специальным именем. Эта модель хорошо документиро) вана в спецификации OPC по адресу www.microsoft.com/whdc/xps/downloads.mspx.

Помимо средств загрузки  ресурсов, объект Application  предоставляет прямой доступ к загрузке компонентов,  определенных в разметке:

public class Application : DispatcherObject, IResourceHost {

public static object LoadComponent(Uri resourceLocator);

public static void LoadComponent(object component, Uri resourceLocator);

}

Эти два перегруженных варианта метода LoadComponent применяются для заг# рузки и разбора компонентов,  написанных на XAML. Первый обращается к методу GetResourceStream и загружает встроенный XAML#ресурс в объект. Наверное, чаще всего он используется для загрузки части описания пользовательского интерфейса.

У любого компонента, написанного  на XAML, есть два имени: URI и имя CLR# типа. Когда объект типа, определенного с помощью разметки, создается с помощью ключевого слова new, конструктор этого типа вызывает метод InitializeComponent, который в свою очередь загружает код на языке XAML. До этого места метод InitializeComponent представлялся какой#то магией. Давайте  потратим  некоторое время, чтобы познакомиться с тем, как он работает на самом деле.

Рис. 2.9. Простой пример: окно с одной кнопкой

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

<!— LoadTest.xaml —>

<Window x:Class=’EssentialWPF.LoadTest’ xmlns=’http://schemas.microsoft.com/winfx/2006/xaml/presentation’ xmlns:x=’http://schemas.microsoft.com/winfx/2006/xaml’ Title=’EssentialWPF’

<Button>Hello World</Button>

</Window>

// LoadTest.xaml.cs

public partial class LoadTest : Window {

public LoadTest() { InitializeComponent();

}

}

Что  произойдет,  если закомментировать вызов  InitializeComponent?  Попро#

буйте, я подожду.

Окно  оказалось  пустым, правильно? Проблема  в том, что внутри  Initialize Component вызывается метод LoadComponent, который  загружает  XAML#до# кумент и генерирует визуальные элементы. Можно сделать это и самостоя# тельно:

public partial class LoadTest : Window {

public LoadTest() {

Application.LoadComponent(this,

new Uri(«LoadTest.xaml», UriKind.Relative));

}

}

Метод InitializeComponent также присваивает значения  некоторым  перемен# ным#членам и подписывается на события, поэтому в общем случае я не рекомен# дую опускать его вызов. Но понимать, что он делает, тем не менее полезно.

Второй  вариант  метода  LoadComponent идентичен  вызову  new  для  типа CLR. Оба варианта  очень сильно различаются, поэтому давать им одинаковые имена было ошибкой. Следующие строки дают в точности один и тот же ре# зультат:

LoadTest load;

load = (LoadTest)Application.LoadComponent(

new Uri(«LoadTest.xaml», UriKind.Relative));

load = new LoadTest();

Здесь четко видны оба имени LoadTest: URI и тип CLR.

Состояние)документ

Состояние#документ – это набор данных, ассоциированных с пользовательс# ким документом  (например, документом  Microsoft  Word  или графическим фай# лом).  Хотя  в .NET  есть службы  для  создания  документов  и манипулирования ими, WPF не предоставляет никакого стандартного  каркаса для управления сос# тоянием#документом.  Эта обязанность возлагается  на автора приложения.

Теперь, когда мы познакомились с объектом Application,  можно попробовать нарисовать  на экране пиксель#другой.  На верхнем уровне приложения располо# жены строительные блоки трех видов: окна, пользовательские элементы управле# ния и страницы.

Источник: К. Андерсон  Основы  Windows Presentation Foundation. Пер. с англ. А. Слинкина — М.: ДМК Пресс, 2008 — 432 с.: ил.

По теме:

  • Комментарии