For those who want to take geometry into their own hands and not rely on WPF's Rectangle and Ellipse components, WPF provides Geometry. This class of objects offers a lot of flexibility. For example, Geometry WPF objects all inherit from a new class, the Freezable class. Essentially, this means they can be made read-only and this, in turn, makes it possible to share them, declare them as resources and make them thread-save (for multiprocessing).
An important technique in using Geometry objects is the Path object. And the most important thing to know about Path is the Data property.
One confusing thing to understand right away is that a Geometry object can't draw itself. In other words the Line component (an object in Shape) can be placed inside a Grid or Canvas and will show up just fine ...
<Line X1="100" Y1="100"
X2="200" Y2="200"
Stroke="Blue" />
But the Geometry counterpart, LineGeometry can't be used that way. If you try to substitute this statement for the one above inside a Canvas ...
<LineGeometry
StartPoint="100,100"
EndPoint="200,200" />
... you just get an error. Path, however, is a Shape and it can render itself. So if you simply make LineGeometry the Data that drives Path, everything works.
<Path Stroke="Red" StrokeThickness="2" >
<Path.Data>
<LineGeometry
StartPoint="100,100"
EndPoint="200,200" />
</Path.Data>
</Path>
There is a really rich collection of objects to do whatever you need in Geometry from LineGeometry shown above to things like PolyQuadraticBezierSegment. We won't try to cover all of that detail here. Just keep in mind that what might seem horribly complex when you look at the whole thing is really simple if you just keep breaking it down into simple parts.
But there is a completely new syntax that is part of Path.Data called Path Markup Syntax that you should at least be aware of. XML has never been a compact language. The rule has always been to spell things out with lots of text rather than save space. Even the simple example above shows that you can start to get lots of lines of XML code with figures of any complexity at all. Especially when another program is actually creating the data (as with the 'random Polyline' above), this doesn't make sense. So a much more compact syntax can be used to specify data points. Using path markup syntax, the example above can also be coded ...
<Path Stroke="Red" StrokeThickness="2"
Data="M 100,100 L 200,200" />
You can find the detailed syntax at Microsoft, but in brief, path markup syntax follows this rule:
<object property="[fillRule] figureDescription[figureDescription]*" ... />
In the example, "object" is "Data"; there is no "fillRule"; and there are two "figureDescriptions" ...
M 100,100
and
L 200,200
... which correspond to ...
StartPoint="100,100"
and
EndPoint="200,200"
If you check out any of the Microsoft documentation, you will quickly see that this introduction only scratches the surface of what WPF graphics can do. As I've noted, there is a wealth of detail and options for 2D graphics that let you do whatever you need. But in addition, there is also 3D graphics and animation that will have to wait for a future article!