<b> установленный в свойстве Data --></b>
<Path Fill = "Orange" Stroke = "Blue" StrokeThickness = "3">
<Path.Data>
<GeometryGroup>
<EllipseGeometry Center = "75,70" RadiusX = "30" RadiusY = "30" />
<RectangleGeometry Rect = "25,55 100 30" />
<LineGeometry StartPoint="0,0" EndPoint="70,30" />
<LineGeometry StartPoint="70,30" EndPoint="0,30" />
</GeometryGroup>
</Path.Data>
</Path>
![]()
Изображение на рис. 26.3 может быть визуализировано с применением показанных ранее классов Line, Ellipse и Rectangle. Однако это потребовало бы помещения различных объектов UIElement в память. Когда для моделирования точек рисуемого изображения используются геометрические объекты, а затем коллекция геометрических объектов помещается в контейнер, который способен визуализировать данные (Path в рассматриваемом случае), то тем самым сокращается расход памяти.
Теперь вспомните, что класс Path имеет ту же цепочку наследования, что и любой член пространства имен System.Windows.Shapes, а потому обладает возможностью отправлять такие же уведомления о событиях, как другие объекты UIElement. Следовательно, если определить тот же самый элемент <Path> в проекте Visual Studio, тогда выяснить, что пользователь щелкнул в любом месте линии, можно будет за счет обработки события мыши (не забывайте, что редактор Kaxaml не разрешает обрабатывать события для написанной разметки).
"Мини-язык" моделирования путей
Из всех классов, перечисленных в табл. 26.3, класс PathGeometry наиболее сложен для конфигурирования в терминах XAML и кода. Причина объясняется тем фактом, что каждый сегмент PathGeometry состоит из объектов, содержащих разнообразные сегменты и фигуры (скажем, ArcSegment, BezierSegment, LineSegment, PolyBezierSegment, PolyLineSegment, PolyQuadraticBezierSegment и т.д.). Вот пример объекта Path, свойство Data которого было установлено в элемент PathGeometry, состоящий из различных фигур и сегментов:
<Path Stroke="Black" StrokeThickness="1" >
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
<Path.Data>
<PathGeometry>
<PathGeometry.Figures>
<PathFigure StartPoint="10,50">
<PathFigure.Segments>
<BezierSegment
Point1="100,0"
Point2="200,200"
Point3="300,100"/>
<LineSegment Point="400,100" />
<ArcSegment
Size="50,50" RotationAngle="45"
IsLargeArc="True" SweepDirection="Clockwise"
Point="200,100"/>
</PathFigure.Segments>
</PathFigure>
</PathGeometry.Figures>
</PathGeometry>
</Path.Data>
</Path>
По правде говоря, лишь немногим программистам придется когда-либо вручную строить сложные двумерные изображения, напрямую описывая объекты производных от Geometry или PathSegment классов. Позже в главе вы узнаете, как преобразовывать векторную графику в операторы "мини-языка" моделирования путей, которые можно применять в разметке XAML.
Даже с учетом содействия со стороны упомянутых ранее инструментов объем разметки XAML, требуемой для определения сложных объектов Path, может быть устрашающе большим, т.к. данные состоят из полных описаний различных объектов классов, производных от Geometry или PathSegment. Для того чтобы создавать более лаконичную разметку, в классе Path поддерживается специализированный "мини-язык".
Например, вместо установки свойства Data объекта Path в коллекцию объектов классов, производных от Geometry и PathSegment, его можно установить в одиночный строковый литерал, содержащий набор известных символов и различных значений, которые определяют фигуру, подлежащую визуализации. Ниже приведен простой пример, а его результирующий вывод показан на рис. 26.4:
<Path Stroke="Black" StrokeThickness="3"
Data="M 10,75 C 70,15 250,270 300,175 H 240" />
![]()
Команда М (от move — переместить) принимает координаты (х, у) позиции, которая представляет начальную точку рисования. Команда С (от curve — кривая) принимает последовательность точек для визуализации кривой (точнее кубической кривой Безье), а команда Н (от horizontal — горизонталь) рисует горизонтальную линию.
