Теперь вспомните, что класс Path
имеет ту же цепочку наследования, что и любой член пространства имен System.Windows.Shapes
, а потому обладает возможностью отправлять такие же уведомления о событиях, как другие объекты UIElement
. Следовательно, если определить тот же самый элемент
в проекте Visual Studio, тогда выяснить, что пользователь щелкнул в любом месте линии, можно будет за счет обработки события мыши (не забывайте, что редактор Kaxaml не разрешает обрабатывать события для написанной разметки).
"Мини-язык" моделирования путей
Из всех классов, перечисленных в табл. 26.3, класс PathGeometry
наиболее сложен для конфигурирования в терминах XAML и кода. Причина объясняется тем фактом, что каждый PathGeometry
состоит из объектов, содержащих разнообразные сегменты и фигуры (скажем, ArcSegment
, BezierSegment
, LineSegment
, PolyBezierSegment
, PolyLineSegment
, PolyQuadraticBezierSegment
и т.д.). Вот пример объекта Path
, свойство Data
которого было установлено в элемент PathGeometry
, состоящий из различных фигур и сегментов:
Point1="100,0"
Point2="200,200"
Point3="300,100"/>
Size="50,50" RotationAngle="45"
IsLargeArc="True" SweepDirection="Clockwise"
Point="200,100"/>
По правде говоря, лишь немногим программистам придется когда-либо вручную строить сложные двумерные изображения, напрямую описывая объекты производных от Geometry
или PathSegment
классов. Позже в главе вы узнаете, как преобразовывать векторную графику в операторы "мини-языка" моделирования путей, которые можно применять в разметке XAML.
Даже с учетом содействия со стороны упомянутых ранее инструментов объем разметки XAML, требуемой для определения сложных объектов Path
, может быть устрашающе большим, т.к. данные состоят из полных описаний различных объектов классов, производных от Geometry
или PathSegment
. Для того чтобы создавать более лаконичную разметку, в классе Path
поддерживается специализированный "мини-язык".
Например, вместо установки свойства Data
объекта Path
в коллекцию объектов классов, производных от Geometry
и PathSegment
, его можно установить в одиночный строковый литерал, содержащий набор известных символов и различных значений, которые определяют фигуру, подлежащую визуализации. Ниже приведен простой пример, а его результирующий вывод показан на рис. 26.4:
Data="M 10,75 C 70,15 250,270 300,175 H 240" />
Команда М
(от х
, у
) позиции, которая представляет начальную точку рисования. Команда С
(от Н
(от
И снова следует отметить, что вам очень редко придется вручную строить или анализировать строковый литерал, содержащий инструкции мини-языка моделирования путей. Тем не менее, цель в том, чтобы разметка XAML, генерируемая специализированными инструментами, не казалась вам совершенно непонятной.
Кисти и перья WPF
Каждый способ графической визуализации (фигуры, рисование и геометрические объекты, а также визуальные объекты) интенсивно использует кисти, которые позволяют управлять заполнением внутренней области двумерной фигуры. Инфраструктура WPF предлагает шесть разных типов кистей, и все они расширяют класс System.Windows.Media.Brush
. Несмотря на то что Brush
является абстрактным классом, его потомки, описанные в табл. 26.4, могут применяться для заполнения области содержимым почти любого мыслимого вида.
Классы DrawingBrush
и VisualBrush
позволяют строить кисть на основе существующего класса, производного от Drawing
или Visual
. Такие классы кистей используются при работе с двумя другими способами визуализации графики WPF (рисунками или визуальными объектами) и будут объясняться далее в главе.
Класс ImageBrush
позволяет строить кисть, отображающую данные изображения из внешнего файла или встроенного ресурса приложения, который указан в его свойстве ImageSource
. Оставшиеся типы кистей (LinearGradientBrush
и RadialGradientBrush
) довольно просты в применении, хотя требуемая разметка XAML может оказаться многословной. К счастью, в среде Visual Studio поддерживаются интегрированные редакторы кистей, которые облегчают задачу генерации стилизованных кистей.
Конфигурирование кистей с использованием Visual Studio