In WPF is there a way that you can modify the way any path is drawn APART from Dash-Dot sequences? Say I want draw a triple line for any path I am drawing or small triangles,waves..etc on the drawing path itself. I have tried Brushes but it will not follow the Path. Please help
thx
WPF's Geometry classes have all the primitives you need to accomplish this easily, but you will need to do it in code. When I need to do custom lines I usually construct a Drawing based on the Geometry, but in your case you can simply build a Geometry that has three lines in parallel and stroke that.
Start with PathGeometry.CreateFromGeometry() to get a PathGeometry for the input path
Use GetWidenedPathGeometry(), passing in the desired spacing, to get a new geometry whose edges correspond to the side lines
(optional) Remove segments at the end of the widened geometry, if desired
Combine the side line geomerty with original geometry using a CombinedGeometry
Stroke the combined geometry to get a triple line
More explanation on step 3: The widened geometry has line segments at the end of the original line. This causes a line to be drawn across the end of your line, which actually looks aesthetically pleasing in many situations. If your situation would look better without it, remove it by iterating the side line geometry and removing all line segments that pass through the endpoints of the original path.
The above takes about 8 lines of code if you don't strike off the ends, or 15 if you do.
A trick to make this convenient is to create an attached property which effectively coerces the Data property of the Path control it is attached to. With such an attached property, all you need to write is:
<Path TripleStroke.Enable="true" Data="..." />
If you know how to implement attached properties and register handlers in them, this is a piece of cake. If not, plan on spending several hours learning how to code attached properties to simulate value coercion before implementing the attached property approach.
Update
The basic technique I describe above can also be extended to allow an arbitrary pattern to be applied along a path. For an example, see custom brushes in the Expression Design tool. There is nothing built into WPF to do this for you, however, so you'll need to create it yourself, and I can tell you from experience that it is a lot of work. Here are the basic steps:
First create a method that takes a Geometry an existing Drawing, and some parameters for end caps, etc and creates a new Drawing that repeats the given Drawing along the path given by the Geometry. Then it is easy to draw a stroked path: Create a Drawing to describe the custom stroke, then display the stroke using a DrawingVisual that contains a Binding with a converter that calls your conversion method.
To actually implement the conversion method:
Convert the source drawing into a set of GeometryDrawing objects (I also supported ImageDrawing but that is more complicated since you need to use the 3D system to stretch the images). This is done by recursing through DrawingGroup objects, keeping track of transforms as you go, and constructing GeometryDrawings with appropriate transform.
Remove portions of geometry in the "end cap" areas of the original drawing and set them aside.
Iterate along the path, duplicating the GeometryDrawing objects repeatedly with appropriate coordinate transformations applied to all coordinates in the geometry.
Process the "end cap" sections of the geometry using the same procedure.
Also note in step 1 that any GlyphRunDrawings are handled using FormattedText.BuildGeometry to create an equivalent GeometryDrawing.
There is no supported method for doing this in WPF. The solution is going to involve either composite Path objects or fancy code-behind gymnastics. Are you specificly looking for a triple-line path implementation?
Related
I've got an array of points (X,Y) which constitute a convex hull (a simple, irregularly shaped contour). Rather than rendering a polygon with straight edges, I want to render them with an approximate "smoothly curved" contour that passes through all of these points.
In WinForms/GDI+, this could be accomplished with the Graphics.DrawClosedCurve or Graphics.FillClosedCurve methods. There does not appear to be an equivalent in WPF.
I've looked into drawing using things like Path and BezierSegment, but I'm not sure if (and how) these can be used to generate a continuous closed curve, given a set of points. It appears that to do this, I'd perhaps have to generate a set of control points based on my contour as an intermediate step?
I have tried using the GDI+ methods to render onto a System.Drawing.Bitmap and then displaying that in the WPF application. This works, but the performance (particularly the conversion from System.Drawing.Bitmap to BitmapSource) is poor and not sufficient for the application. This is why I'm looking for a pure WPF solution.
Has anyone been able to draw a closed curve based off a set of points in WPF?
Unfortunately, there is no single-method equivalent to DrawClosedCurve in WPF, even though it's been requested. So you are left with at least two options:
Host a native window within your WPF window and perform all your drawing on it.
Implement your own cardinal spline drawing. You are on the right track with Bezier segments. However, there are existing implementations of it you can look at out there.
I'm currently looking to achieve a gradient effect a bit like the rectangle in http://pjnicholson.com/Fireworks/fillgradients.htm
If I compromise a little I can get close to this using RadialGradientBrush... but is there any (not too painful) way to achieve the rectangular effect?
Use an ImageBrush instead and use this image (or a similar image generated using some image editor) for the background of your rectangle.
One solution a colleague and I came with was to derive a new Panel that used a WriteableBitmap as the source for its background.
The panel will give you the dimensions you need to make your WriteableBitmap. Using whatever algorithm you want you can fill it appropriately. In our case, we needed a radial or cone gradient, but the same concept applies.
Additionally, you can create several properties on your new control to specify the colors for the gradient. We adapted a LinearGradientBrush for our needs, but if you're working on just two colors, simple properties may suffice.
I don't have the code handy but will try to find it and post an update later. But the above should get you going.
We have a control which we do our own custom drawing in OnRender. However, we would like to use a PNG with transparency as sort of a stencil for various drawing 'passes' if you will.
Now we already know that we can simply use a PNG in an ImageBrush and set it as the control's OpacityMask, but we actually want to do several drawing passes with several different stencils. If we wanted to go the OpacityMask route, we'd have to create separate controls, separate ImageMasks, then stack them all up on top of each other which also clutters up your visual tree.
We don't want to do that. We want to do all of the drawing in the OnRender override of a single Control subclass. We just want those draw calls to be masked out by an image. We then want to repeat that over and over until our drawing is done.
Any way this can be done?
HA! Found it! Odd that the S/O community has been so quiet on this one, but for those looking for it, it's called DrawingContext.PushOpacityMask (and the corresponding 'Pop()') and does exactly what you think it does... it pushes an opacity mask (via a brush) onto the DC and all subsequent drawing is relative to the brush's opacity values.
You can also layer 'masks' for some pretty cool effects too. They are additive, not just the last one set.
I'm pretty sure the built-in OpacityMask is just used with this function in the OnRender call. What this means is you can still use the OpacityMask (provided you push that on first) then your own mask(s) for your own drawing calls. Pretty neat stuff!
Hope this helps others who were looking for this.
I'm currently creating a MSPaint-like WPF-application and struggling with the implementation of a snappable grid.
The painting of the grid is no problem with a VisualBrush and a Rectangle but the problem is that these lines are then purely for looks and can't be easily changed (for example highlighted when the snapping to a specific line triggered).
My other idea was to have a 2 Canvas solution where 1 Canvas is used for the elements and one Canvas (who is positioned above the other) contains all the grid lines. However I have the feeling that this would mean quite a performance hit.
Are there any other possible ways to implement this kind of functionality?
Efficiency considerations of a two-panel approach vs DrawingContext
I have good news for you: You are wrong about the significant performance hit. Your two-canvas idea is nearly optimal, even if you use individual objects for the grid lines. This is because WPF uses retained-mode rendering: When you create the canvas, everything on it is serialized into a compact structure at native level. This only changes when you change the grid lines in some way, such as changing the grid spacing. At all other times the performance will be indistinguishable from the very fastest possible managed-code methods.
A slight performance increase could be had by using DrawingContext as Nicholas describes.
A simpler and more efficient solution
Perhaps a better way then drawing individual lines on the grid canvas is to use two tiled visual brushes (one horizontal, one vertical) to draw all unhilighted lines, then use Rectangle(s) added in code-behind to hilight the line(s) you are snapping to.
The main advantage of this technique is that your grid can be effectively infinite, so there is no need to calculate the right number of grid lines to draw and then update this every time the window resizes or the zoom changes. You also only have three UIElements involved, plus one more for each grid line that is currently hilighted. It also seems cleaner to me than tracking collections of grid lines.
The reason you want to use two visual brushes is that drawing is more efficient: The brush drawing the vertical lines is stretched to a huge distance (eg double.MaxValue/2) in the vertical direction so the GPU gets only one drawing call per vertical line, the same for the horizontal. Doing a two-way tiling is much less efficient.
Adorner layer
Since you asked about alternatives, another possibility is to use Adorner and AdornerLayer with any of the solutions above rather than stacking your canvas using eg a Grid or containing Canvas. For a Paint-like application this is nice because the adorner layer can be above your graphic layer(s) yet the adorners can still attach to individual items that are being displayed.
You might consider drawing your grid using the DrawingContext inside of OnRender. Drawing this way does not introduce new UIElements into the visual tree, which helps to keep performance up. In some ways, it is similar to what you are currently doing with the VisualBrush, which also does not create new UI elements per copy.
However, since you will actually be individually drawing each line instead of copying the look of a single line, you'll be able to highlight the grid line(s) that participate in snapping without changing the colors of those that do not.
If you are going to go down this route, make sure to have a look into GuidelineSets for positioning your guide lines (more details here), since you'll probably want to have your guide lines snap to the device's pixels so that they draw sharply.
I need to write a gauge control in WPF for a project at work. By gauge control, I mean something akin to a traditional car speedometer: a circular face with numbers and ticks around the circumference, and a needle pointing to the current value. Although I could get my employer to purchase a third-party control, or even find a free one somewhere, I’d still like to write it myself, for curiosity’s sake more than anything else.
My first thought was to ‘skin’ an existing control using a template, something like a ProgressBar for example as it has Minimum, Maximum and Value properties. However, I don’t think this will offer me the flexibility that I need.
I’d like to animate the needle that points to the current value, so that when the gauge’s value changes the needle moves from the old value to the new value. I figured the easiest way to do this would be to have some kind of shape or geometry representing the needle, and then apply a RotateTransform of the relevant number of degrees to get the needle to point to the correct value. The animation’s To property would be set to the ‘value degrees’ property via binding.
It seems to me that there are three basic approaches I could take:
Use one custom FrameworkElement to represent the entire gauge
I could derive from FrameworkElement, override its OnRender method, then use the DrawingContext to draw both the gauge face and the needle. This would mean that I could no longer animate the needle directly using a RotateTransform, but would instead have to redraw the entire gauge every time the value changes. This seems inefficient to me, as the gauge face represents the bulk of the drawing code but would change very rarely. However, this approach is the most lightweight in terms of the number of elements used.
Use two custom FrameworkElements, one for the face and one for the needle
I’m currently leaning towards this approach. One element would represent the face, the other the needle. This would allow me to target the needle element with the RotateTransform. The gauge control would then consist of three elements: the face, the needle, and a Panel container to hold both of them (ie. Canvas, Grid, whatever). So three elements instead of one, hence not as lightweight as the first approach.
Use DrawingVisuals to draw the face and needle
I’ve also read about the DrawingVisual class, but I’m a bit confused as to why anyone would use this as opposed to deriving from FrameworkElement and overriding OnRender, given that DrawingVisual must be hosted in a custom FrameworkElement anyway. It would seem that this approach doesn’t offer any advantages over the second approach, and would require more code, but maybe I’m missing something.
Any thoughts or advice regarding which approach people think is best and why would be most welcome!
Personally I'd recommend making a CustomControl using the second approach. Unless you are going to be showing more than 1000 of the gauges in view at the same time you aren't going to notice the extra element in your visual tree and I think you'll find it's much easier to make and maintain.
You could just style a slider control and feed values into it. You should be able to make a slider look like any kind of gauge you need.