Diagram: Expose shape and connection events on a control level

Progress® Telerik® UI for Silverlight (discontinued) Feedback Portal

Create an account Log In

Back to Feed

Request a Feature Report a Bug

Unplanned

Last Updated: 03 Jan 2017 21:01 by Juan

Juan

Created on: 14 Jan 2014 22:07

Category: Diagram

Type: Feature Request

Diagram: Expose shape and connection events on a control level

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.

2 comments

Juan

Posted on: 15 Apr 2014 01:02

Hi Tina.

Yes, I understand (like mentioned in my message) there are ways to subscribe and/or capture the flow of most every event. However, I guess what I was hinting is the following: why is it so simple and direct to set the handler for when ANY shape in the diagram is clicked or double-clicked (you simply wire the ShapeClicked or ShapeDoubleClicked events DIRECTLY in the XAML definition of the RadDiagram, and the specific shape is passed as a parameter), whereas it is much more cumbersome to do the same for, for instance, all those edit-related events? Like explained in the first message, I envisioned ShapeBeginEdit, ShapeEndEdit, etc... events IN THE DIAGRAM CONTROL (RadDiagram), which performed exactly the same as the existing ones.

This will avoid having to do all that wiring in code behind, dynamically and manually (in scenarios where the RadDiagramItems are sourced from a ViewModel, which should be most real-world scenarios anyway) for each new item inserted, etc, etc. Which, again, it's obviously what I've had to do, but I felt this could be functionality the control should have simplified for me.

Cheers,

Juan

ADMIN

Tina Stancheva

Posted on: 03 Apr 2014 09:47

Hello Juan,

All RadDiagramItems expose the following set of events:
- PreviewBeginEdit - occurs when item is about to be edited.
- BeginEdit - occurs when item has entered edit mode.
- PreviewEndEdit - occurs when item is about to exit the edit mode.
- EndEdit - occurs when item is edited (exited the edit mode).
You can easily subscribe to those in the definition of the items or in code-behind when the items are dynamically generated. For instance you can use the Telerik.Windows.AddHandler to attach a handler to all RadDiagramShapes BeginEdit events being propagated to a specific RadDiagram instance:
xDiagram.AddHandler(RadDiagramShape.BeginEditEvent, new RadRoutedEventHandler(OnDiagramShapeBeginEdit));
However, if you feel that these events are not handy in specific editing scenarios, please elaborate a bit more on the use cases where you would need such events available in the RadDiagram class.

As for a preview delete, in our Diagramming Framework, the delete operation is handled in a command. The command has a CanExecute and Executed methods and we recommend our customers to customize these methods in case they need custom deletion logic. For instance you can implement a custom CanExecuted method that controls if the delete operation should be executed.

Also RadDiagram exposes ItemsChanges and ItemsChanging events triggered when adding and removing items in the component. It also exposes GraphSourceChanged and GraphSourceChanging events that are fired when the GraphSource of a data-bound RadDiagram is changed. Additionally, in an MVVM implementation the Diagramming Framework exposes a few useful ViewModels (for instance ObservableGraphSourceBase) where you will be able to create custom logic when removing a link or a node.

Having the above information in mind, at this point we don't believe that exposing the events you described will bring additional value to the component. However, I set the status of this item to UnderReview so that you can share any additional feedback or scenarios that we might have not considered. We will gladly discuss your further feedback and decide on the implementation of the suggested events.