Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

от глаз. В главе 25 мы рассмотрим свойства зависимости более подробно.

Роль класса System.Windows.Threading.DispatcherObject

Последним базовым классом для типа Window (помимо System.Object, который здесь не требует дополнительных пояснений) является DispatherObject. В нем определено одно интересное свойство Dispatcher, которое возвращает ассоциированный объект System.Windows.Threading.Dispatcher. Класс Dispatcher — это точка входа в очередь событий приложения WPF, и он предоставляет базовые конструкции для организации параллелизма и многопоточности. Объект Dispatcher обсуждался в главе 15.

Синтаксис XAML для WPF

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

Введение в Kaxaml

Когда вы только приступаете к изучению грамматики XAML, может оказаться удобным в применении бесплатный инструмент под названием Kaxaml. Этот популярный редактор/анализатор XAML доступен по ссылке https://github.com/punker76/kaxaml.

На заметку! Во многих предшествующих изданиях книги мы направляли читателей на веб-сайт www.kaxaml.com, но, к сожалению, он прекратил свою работу. Ян Каргер (https://github.com/punker76) сделал ответвление от старого кода и потрудился над его улучшением. Его версия инструмента доступна в GitHub по ссылке https://github.com/punker76/kaxaml/releases. Стоит выразить благодарность создателям за великолепный инструмент Kaxaml и Яну за то, что он сохранил его; Kaxaml помог многочисленным разработчикам изучить XAML.

Редактор Kaxaml полезен тем, что не имеет никакого понятия об исходном коде С#, обработчиках ошибок или логике реализации. Он предлагает намного более прямолинейный способ тестирования фрагментов XAML, нежели использование полноценного шаблона проекта WPF в Visual Studio. К тому же Kaxaml обладает набором интегрированных инструментов, в том числе средством выбора цвета, диспетчером фрагментов XAML и даже средством "очистки XAML", которое форматирует разметку XAML на основе заданных настроек. Открыв Kaxaml в первый раз, вы найдете в нем простую разметку для элемента управления <Page>:

<Page

  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

  <Grid>

  </Grid>

</Page>

Подобно объекту Window объект Page содержит разнообразные диспетчеры компоновки и элементы управления. Тем не менее, в отличие от Window объекты Page не могут запускаться как отдельные сущности. Взамен они должны помещаться внутрь подходящего хоста, такого как NavigationWindow или Frame. Хорошая новость в том, что в элементах <Page> и <Window> можно вводить идентичную разметку.

На заметку! Если в окне разметки Kaxaml заменить элементы <Page> и </Page> элементами <Window> и </Window>, тогда можно нажать клавишу <F5> и отобразить на экране новое окно.

В качестве начального теста введите следующую разметку в панели XAML, находящейся в нижней части окна Kaxaml:

<Page

  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

  <Grid>

    <!-- Кнопка со специальным содержимым -->

    <Button Height="100" Width="100">

      <Ellipse Fill="Green" Height="50" Width="50"/>

    </Button>

  </Grid>

</Page>

В верхней части окна Kaxaml появится визуализированная страница (рис. 24.2).

Во время работы с Kaxaml помните, что данный инструмент не позволяет писать разметку, которая влечет за собой любую компиляцию кода (но разрешено использовать х:Name). Сюда входит определение атрибута х:Class (для указания файла кода), ввод имен обработчиков событий в разметке или применение любых ключевых слов XAML, которые также предусматривают компиляцию кода (вроде FieldModifier или ClassModifier). Попытка поступить так приводит к ошибке разметки.

Пространства имен XML и "ключевые слова" XAML

Корневой элемент XAML-документа WPF (такой как <Window>, <Page>, <UserControl> или <Application>) почти всегда будет ссылаться на два заранее определенные пространства имен XML:

<Page

  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

  <Grid>

  </Grid>

</Page>

Первое пространство имен XML, http://schemas.microsoft.com/winfx/2006/xaml/presentation, отображает множество связанных c WPF пространств имен .NET для использования текущим файлом *.xaml (System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Ink, System.Windows.Media, System.Windows.Navigation и т.д.).

Это отображение "один ко многим" в действительности жестко закодировано внутри сборок WPF (WindowsBase.dll, PresentationCore.dll и PresentationFramework.dll) с применением атрибута [XmlnsDefinition] уровня сборки. Например, если открыть браузер объектов Visual Studio и выбрать сборку PresentationCore.dll, то можно увидеть списки, подобные показанному ниже, в котором импортируется пространство имен System.Windows:

[assembly: XmlnsDefinition(

    "http://schemas.microsoft.com/winfx/2006/xaml/presentation",

    "System.Windows")]

Второе пространство имен XML, http://schemas.microsoft.com/winfx/2006/xaml, используется для добавления специфичных для XAML "ключевых слов" (термин выбран за неимением лучшего), а также пространства имен System.Windows.Markup:

[assembly: XmlnsDefinition(

    "http://schemas.microsoft.com/winfx/2006/xaml",

    "System.Windows.Markup")]

Одно из правил любого корректно сформированного документа XML (не забывайте, что грамматика XAML основана на XML) состоит в том, что открывающий корневой элемент назначает одно пространство имен XML в качестве первичного пространства имен, которое обычно представляет собой пространство имен, содержащее самые часто применяемые элементы. Если корневой элемент требует включения дополнительных вторичных пространств имен (как видно здесь), то они должны быть определены с использованием уникального префикса (чтобы устранить возможные конфликты имен). По соглашению для префикса применяется просто х, однако он может быть любым уникальным маркером, таким как XamlSpecificStuff:

<Page

  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

  xmlns:XamlSpecificStuff="http://schemas.microsoft.com/winfx/2006/xaml">

  <Grid>

    <!-- Кнопка со специальным содержимым -->

    <Button XamlSpecificStuff:Name="button1" Height="100" Width="100">

      <Ellipse Fill="Green" Height="50" Width="50"/>

    </Button>

  </Grid>

</Page>

Очевидный недостаток определения длинных префиксов для пространств имен XML связан с тем, что XamlSpecificStuff придется набирать всякий раз, когда в файле XAML нужно сослаться на один из элементов, определенных в этом пространстве имен XML. Из-за того, что префикс XamlSpecificStuff намного длиннее, давайте ограничимся х.

Помимо ключевых слов x:Name, х:Class и x:Code пространство имен http://schemas.microsoft.com/winfх/2006/xaml также предоставляет доступ к дополнительным ключевым словам XAML, наиболее распространенные из которых кратко описаны в табл. 24.9.

В дополнение к двум указанным объявлениям пространств имен XML можно (а иногда и нужно) определить дополнительные префиксы дескрипторов в открывающем элементе документа XAML. Обычно так поступают,