This behavior is causing problems like when I open a saved diagram, on load the there is a bumpy load and looks like diagram is going criss-cross. Sometimes the user maybe confused when dragging dropping nodes too. I tried to disable it in the control template and in the TemplateApplied event. But it doesnt work. I have set these 2 properties on the diagram ScrollViewer.HorizontalScrollBarVisibility=“Visible”
ScrollViewer.VerticalScrollBarVisibility=“Visible”
I am unclear about what the problem is and exactly what behavior you want instead. What do you mean by “going criss-cross”? How can the user get confused when dragging nodes?
If the user drops a node so that it crosses the edge of the viewport, and if the DiagramBounds is small enough at the current Scale to fit within the viewport, then the document is scrolled slightly so that everything is visible.
Attaching a video here Goxam issues The load of a diagram has lot of movement before it can settle. I have a padding of thickness(400)
The diagram looks pretty good, although I wonder if you’d prefer using Route.Curve being JumpGap instead of JumpOver.
I don’t understand exactly what I’m seeing. When only the two reddish nodes were showing, did you then invoke some command to show the big graph?
Starting at about 9 seconds, it seems there are only ports showing plus an Undo History panel.
Then at around 16 seconds, it shows a lot (but not all) of the nodes and links and the Undo History panel disappears.
Then at around 17 seconds, it shows what I assume is all of the nodes and links, scaled down to fit in the now-expanded viewport.
Then at around 19 seconds, it zooms in to show the middle-left area of the nodes and links.
Then at around 21 seconds, it scrolls to show the top-left area of the nodes and links.
So it seems to me that you should remove the “Undo History” panel first, so that the size of the Diagram component (i.e. what is shown in the viewport) is the final size that you expect it to have. That will avoid one set of adjustments in DiagramPanel.Scale and Position that is causing redrawing.
It appears that there’s a ZoomToFit happening first, followed by some sort of zooming and then scrolling. I can’t explain that, except that maybe layouts are being animated. Set LayoutManager.Animated to false.
Another possibility is to try removing all settings and code that directly or indirectly changes DiagramPanel.Scale or Position, such as DiagramPanel.Stretch or your own code to set Scale or Position, to see what happens without any automatic zoom-to-fit?
To help debug this you can implement a ViewportBoundsChanged listener to notice each time these scrolls and zooms and viewport size changes happen.
JumpOver is a customer requirement here. The nodes take a little time and the pins load first, am just rendering nodes links, nothing special with undo command window, it was open as I was solving another bug, ignore that, am not sure after I set padding why the load is not so smooth anymore, will Debug around the pointers you provided, Thanks for a detailed reply. The zoom and zoomtoFit is happening automatically. Will try to do all that you suggested.
This is from one of the samples:
myDiagram.TemplateApplied += (s, e) => {
myDiagram.Panel.ZoomTime = 0;
myDiagram.LayoutManager.Animated = false;
};
Our nodes can expand vertically. When a user scrolls within an expanded node and edits a textbox inside the node, the diagram canvas auto-scrolls upward to re-center the view. This unexpected canvas movement is not desired and disrupts the user experience. How can we handle this case to avoid movement while user is working on such node? So its a numeric updown control , even before he can set a value, the canvas scrolls
It doesn’t make sense to show the text editor outside of the viewport, where the TextBlock has been clipped. So scrolling to make that text editor visible makes sense. This is standard behavior for editing in scrollable panels that we inherit from WPF.
If the text editor would be within the viewport, is the diagram scrolled?
Here is the attached video describing the problem canvasscrolling.mp4
If the node is within the viewport and I edit the textbox within it, then canvas doesnt scroll. I understand that’s a default behavior, but our app requirement is such that the user can stay there while he is editing. So is that achievable with any override implementation?
I don’t understand what you want to do differently. If the input element is outside of the viewport, the user cannot see it, and it is unreasonable to expect them to provide their input without being able to see what it is that they are controlling/entering. It seems to me that scrolling the diagram so that the input element is visible within the viewport is a necessary behavior.
Am aware of the node am editing, and I want to edit the last node in that list, so I expect the canvas to stay put for me to continue editing. This is the current behavior we have in the app DevexpressCanvasBehavior.mp4
Oh, so maybe the problem is that the last textbox is automatically getting focus when you don’t want it to. I don’t think that happens automatically, so I don’t know what might be causing that.
Suppressing the RequestBringIntoView at the nodetemplate level with e.handled = true; solved this