Provide helper classes to import data from different providers: - Excel (xlsx) - Access (accdb) - OLEDB - ODBC
Top and left connectors are a little bit misplaced in SL
The options provided by the SettingsPane in all online demos should be consistent with the options that can be properly applied to the underlying object. For example users are allowed to set border brush and border thickness to RadDiagramTextShape which does not support any borders by design.
When I use the Sugiyama layout in RadDiagram it puts the node I add first at the bottom and the node I add last at the top for simple graphs without cycles and Orientation.Horizontal. Also the edges of some nodes have a bias to connect to the left side, even when there is no room to connect there in Orientation.Horizontal. The Orientation.Vertical works better for simple diagrams without cycles, but also becomes out of order when I use a cycle.. This is for both WPF and SIlverlight, I attached a demo to hopefully make this clearer. Also Orientation.Vertical and Orientation.Horizontal seem swapped around: I asumed vertical meant top to bottom.
Even though there are workarounds for everything, from my point of view the diagram control will be much enhanced if there are a few events added to it. Just as there are events for a shape having been clicked and double-clicked, in my opinion it will very much help if there would also be events exposed for a shape begin edit, end edit, preview delete (so as to handle a delete event), even generically a PropertyChanged event for any shape in the diagram. And the same for connections would, I imagine, be useful in other scenarios (even if not mine, currently). These are all events I’ve had to handle some other way (sometimes in quite convoluted ways :P), I’m sure there are others which would make life easier for programmers in other scenarios.
RadDiagram control doesn't fire MouseLeftButtonDown/Up events. We are declining this bug report. Diagram needs to handle these events by design. It was our miss these events were not handled in the previous versions of RadDiagram till Q1 2015. We will list this in the breaking changes in our release notes as well.
If you add a background brush to the image export and the export DPI is different than 96d the brush won't be exported correctly. Fixed in LIB version: 2014.2.0914
RadDiagramContainer is resized unexpectedly if you try to align it and its children to the top, bottom, left or right Fixed in LIB version: 2014.2.0914
When using animations on refreshing the layout of a RadDiagram (LayoutSettings.AnimateTransitions = true, then calling Diagram.Layout or Diagram.LayoutAsync), if you have a RadDiagramThumbnail "synchronized" with the RadDiagram... well, the synchronization does not happen automatically (just this I believe is a miss on the part of the Diagramming Framework) and, if you force it with a call to RefreshThumbnail(), since both the Layout and the RefreshThumbnail processes run on the UI thread they seem to collide and the result is the thumbnail isn't correctly refreshed either. Obviously, best would be for those theoretically-synchronized controls to really work in-sync even when animations are on (they seem to work ok for animations off). But at a minimum if the RadDiagram had an event that was thrown when a Layout operation has finalized, we could listen to that event and call the RefreshThumbnail then. ====== Update: RadDiagram provides public DiagramLayoutComplete event. This event is available since Q2 2012.