i want to create a 2d-editor like application in WPF an i need to know how to do this:
How can intercept the event when i click on a Line or Polyline?
How can detect the end / beginning of a line and show a small dot or small box in the end or the beginning of the line. Is there a way to raise an event if i get close of end or the beginning of the line?
How can i create a panning and zooming functionality? How can i control the canvas for that functionality?
How can i maintain the aspect ratio between X and Y and the scale. I mean if i have a horizontal line of length 5 and a vertical line of length 5, what do i have to do to both lines look the same length visually?
Thanks for your answers.
Eduardo
I don't know much, but the ideas that came to my mind are as below, correct me if anything wrong.
Using Hit-Testing [Ref] or Pre-defined extendable Shapes [Ref], which already have common Input events (like MouseEnter, MouseLeave, ...)
For showing a small dot, u can use Adorners. Every line a has end and start point, u can just get it's value and adjust your visual (small dot) for them. Yes, Adorner can help u, they are just like any other UIElement, so commons events like MouseEnter, MouseLeave, ... are there.
For panning and zooming, u can use the code from here or here or here
The lines will be visually same. Just draw them using Shapes (link above).
Related
I'm using wpf with live charts library.
While I draw line chart, I want to add emphasis line on specific label.
It can be a important date with an event.
At first, I added another lineseries about the event. to use geometry
as a marker. But the geometry is somewhat small. Therefore some people couldn't find the event data.
So I want to add lines at tham. But I don't know how to.
Can someone help me?
As the title suggests, how do I find the caret position of a WPF textbox in screen or form-space coordinates? So far, I've only been able to find how to get the character position of the caret in the textbox.
Perhaps I'm getting ahead of myself though, because really, I'm trying to ensure that the current caret position of the selected TextBox (of dynamic height) contained within a DataGrid is visible to the user. So, if there's a way to do this without knowing the coordinates of the caret, then I'm all ears. So far, I've tried calling the DataGrid's ScrollIntoView method, but this can fail if the TextBox is taller than the available screen space.
I don't believe you can do it natively, but you call use interop to call the Win32 GetGUIThreadInfo(). See here for an example: How to call GetGUIThreadInfo in c#
I would suggest something but I don't know if it is applicable in your case. I needed to create a triangular caret to replace the vertical-line caret of a WPF textbox. I control its location with a translate transform and it is always following the default textbox caret. In this way you know where is your new caret is inside the text box (by knowing the X and Y of its translate transform) and then you can use PointToScreen to convert it to screen coordinates.
I really want to create circular slider. I've been searching, but I can't find any information. So any tutorial, guide or if someone already created like this. Please post their XML code.
Instead of making a circular slider (which as #auburg points out) would be a little unintutive to use (think the old telephone dials), consider making it a dial like a thermostat:
It's functionally very similar, but has a much larger hit-test area and is therefore less easy to mess-up for the user.
Try this guide: https://blogs.msdn.microsoft.com/jerrynixon/2012/12/06/walkthrough-building-a-sweet-dial-in-xaml-for-windows-8/
A circular slider can be implemented just like a normal horizontal or vertical slider. The only difference would be that in the MouseMove event handler of the thumb during the drag operation you cannot just handle the horizontal or vertical position. Instead you have to calculate the angle relative to the center of the slider and map that to the value of the slider.
I need to write the following component in WPF:
It should be over image, I should able to drag the lines with the mouse (drag X up and down, drag Y left and right, and Z spin from horizontal to vertical)
My backround in WPF is almost not exist,
Can you give me guidliness? do you know component that doing it, or something similar to that?
Do you know what is the name of this control?
Thanks.
I refactored the program in
http://www.codeproject.com/KB/WPF/WPFDiagramDesigner_Part1.aspx
In the code I just remark
//Canvas.SetTop(designerItem, top + e.VerticalChange);
And remain
Canvas.SetLeft(designerItem, left + e.HorizontalChange);
Delete almost everything, replaced image with rectangle,
And now the verical and horizontal lines drag and drop lines work,
Now I am searching how to do the diagonal line drag and drop
(I tried to do it with path/line control, I had the problem that if I add the diagonal line, it capture all the mouse event, and I can't move the other lines)
Help still needed
I managed to do it,
You can download the code here
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.