StackOverflowException is thrown when the Layout() method of RadDiagram is called and the diagram's router is OrgTreeRouter. To reproduce this use TreeLayoutSettings.
To work this around, add bigger HorizontalSeparation and VerticalSeparation for the TreeLayoutSettings. Or disable the connections routing using the RouteConnections property of RadDiagram.
RadDiagram with virtualization turned off. Randomly positioned 5000 shapes are added in Diagram. For the test, Shapes are with simplified template consisting pretty much of a single Border and nothing else. On maximized WPF window, Diagram Load for about 3-3.5 seconds. On normal WPF window, DIagram loads for about 15 seconds.
While performing Cut operation inside RadDiagram, an exception in the MS Clipboard occurs with the following message:
System.Runtime.InteropServices.COMException: 'OpenClipboard Failed (Exception from HRESULT: 0x800401D0 (CLIPBRD_E_CANT_OPEN))'
If we have a custom shape that derives from RadDiagramShapeBase and we rotate it at some degree (90) for example, and then resize it the diagram's selection adorner is misplaced with the shape. Workaround:
Set RenderTransofrmOrigin = new Point(0.5, 0.5) to the shape.
Other workaround: Derive the custom shape from RadDiagramShape, instead of RadDiagramShapeBase.
To reproduce this use the following code snippet:
<
telerik:RadDiagram
>
<
telerik:RadDiagramShape
Content
=
"Shape 1"
Position
=
"100, 100"
/>
<
telerik:RadDiagramShape
Content
=
"Shape 2"
UseGlidingConnector
=
"True"
Position
=
"300, 100"
/>
</
telerik:RadDiagram
>
Steps to reproduce:
1. Start a new connection from Shape 1, by dragging one of its connectors.
2. Drag the connection over Shape 2.
Expected: The connector closest to the mouse should get highlighted and when you drop the connection it should get attached to the shape.
Actual: The closest connector is not highlighted. Also, when you drop the connection over the target shape it doesn't get attached.
The exception is thrown for the RotationAngle property.
The issue can be observed also in the opposite direction - the diagram is serialized on a machine with some culture (for example Portugal Porguese - pt-PT) and then restored on a machine with an English culture.
The issue reproduces only when saving and loading between cultures which numeric separators are different. For example, with Bulgarian culture, the number 4.5 is represented as 4,5 (with a comma). With English culture the number will be represented as 4.5 (with a period).
To work this around, create a custom RadDiagramShape and override its Deserialize() method. Then parse the RotationAngle manually, and set it to the RotationAngle property of the shape. After this, set the RotationAngle of the SerializationInfo to null, in order to prevent the default restoring of the property.
public
partial
class
CustomShape : RadDiagramShape, IEquatable<BaseShape>
{
public
override
void
Deserialize(SerializationInfo info)
{
if
(info[
"RotationAngle"
] !=
null
)
{
var angle = Convert.ToDouble(info[
"RotationAngle"
].ToString(), CultureInfo.InvariantCulture);
this
.RotationAngle = angle;
info[
"RotationAngle"
] =
null
;
}
base
.Deserialize(info);
}
}
You should be able to prevent the horizontal/vertical overlapping of routed connections . This way the connections should be easier to differentiate. To better differentiate connections, users might: --- use labels on the connections --- use bezier connections --- use different colors for different connections --- use more custom connectors and attach the connections to not used connectors -- use AStartRouter instead of the default one (Grid Router)
RadDiagramShape has NULL content but has DataContext and ContentTemplate. In the ContentTemplate there are UIElements defined. Their automation peers are not added in the automation tree. This can be observed in UIVerify tools.
As a workaround, you can create a custom class which derives from RadDiagramConnector and override the Serialize() method. public class CustomConnector : RadDiagramConnector { static CustomConnector() { DefaultStyleKeyProperty.OverrideMetadata(typeof(CustomConnector), new FrameworkPropertyMetadata(typeof(CustomConnector))); } public override SerializationInfo Serialize() { var info = new Telerik.Windows.Diagrams.Core.SerializationInfo(this.GetType()); if (this.Name != null) info[Telerik.Windows.Diagrams.Core.SerializationConstants.ConnectorName] = this.Name; info[Telerik.Windows.Diagrams.Core.SerializationConstants.Offset] = this.Offset.ToInvariant(); if (Telerik.Windows.Controls.DependencyObjectExtensions.IsLocalValueSet(this, RadDiagramConnector.WidthProperty)) info[Telerik.Windows.Diagrams.Core.SerializationConstants.Width] = this.Width.ToInvariant(); if (Telerik.Windows.Controls.DependencyObjectExtensions.IsLocalValueSet(this, RadDiagramConnector.HeightProperty)) info[Telerik.Windows.Diagrams.Core.SerializationConstants.Height] = this.Height.ToInvariant(); this.SerializePrimitives(info); return info; } } }
This is reproducible only if you set the RotationOrigin property to a value different than (0.5,0.5). Also, the rotation angle is wrong only on the first call of the Rotate() method of the service. To work this around you can create a custom RotationService and override its CalculateRotationAngle() method where you can calculate custom angle. http://docs.telerik.com/devtools/wpf/controls/raddiagram/features/services https://github.com/telerik/xaml-sdk/tree/master/Diagram/CustomServices
Setting diagram.UndoRedoService.UndoBufferSize to 0 after doing some undoable action in diagram does not stop the undo operations. This is a regression issue. Expected: UndoBufferSize 0 means no undo possible. RedoBufferSize 0 means no redo possible. Worakround if applicable: Set the UndoBufferSize to 0 after InitializeComponent. (this is if you don't need undo/redo at all).
Using a custom router and gliding connectors may lead to a StackOverflow Exception. The exception is due to an endless update of the connection Start/End points and the ConnectionPoints. Resolution: The fix will be included in R2 2017 SP in June 2017. Generally, avoid using GlidingConnectors and custom Router which calculates intermediate points based on connections' StartPoint/EndPoint. This is а prerequisite of circular dependency between Start/EndPoint and ConnectionPoints. Gliding Connectors essence is to set StartEndPoints and sometimes they are based on the connection points' first and last point. On the other hand, custom router based on Start/EndPoint makes the opposite- connection points depend on start/end. Instead, the client can use the connection.Source.Bounds.Center (Top, Bottom, Left, Right etc) and connection.Target.Bounds.Center(Top, Bottom, Left, Right etc) in a custom router. Available in LIB version: 2017.2.515
-- Add ClearCache method to clear the undo-redo dictionaries used internally or -- make the undo-redo dictionaries auto clear when undo-redo stacks are cleared Available in LIB version: 2016.3.1114 Clear method of Diagram's UndoRedoService now clears the UndoRedo internal cache automatically. What's changed ? The public interface IDiagramContainerGeneratorInternal interface now adds ClearCache method: A) this.Diagram.UndoRedoService.Clear(); will clear the internal undoredo cache which stores model-container relations. Also this will clear the undo/redo command stacks. B) this.Diagram.ContainerGenerator as GenericContainerGenerator<RadDiagramItem>).ClearCache(); will clear ONLY the undoredo cache.