How can i disable this action?
In your ScheduleView sample, i can drop out (in notepad...) of the window application.
I try to override the CanDrop function in ScheduleViewDragDropBehavior with "state" parameter but couldn't do this.
I didn't find hook to fire drop cancel when it happens...
6 Answers, 1 is accepted
Just in case the original question of my colleague Jordi was missing some details:
We want to be able to disable a drop action for an Appointment when the drop target is bound to another Application. In other words: we want to limit drag & drop actions so we can indeed move an Appointment within its parent ScheduleView.
If we wanted to disable a drop event in a control of ours, then we would be able to handle it a drop event of ours fine. However if the drop target is not under our control, like Notepad, or Office Word, or even an instance of Eclipse IDE, then so far we have not yet found any way to catch the drop action to be able to and cancel it. As a result the appointment gets removed from its ScheduleView, and a text gets inserted with the content of the appointment body or subject in NotePad, or Word…
On one hand the dropped text is a bit funny (and could even be a bit helpful), but on the other hand, we know our end users will be confused by the loss of their appointment.
Is the description clear enough? Any clue to move forward?
You could easily customize the DragDropBehavior of the ScheduleView not to remove the appointment when it is dropped outside the control - just need to override DragDropCompleted method and comment the call to the base class:
For some more detailed information concerning the DragDrop behavior of RadScheduleView, please check the following article from our help documentation:
Hope this helps.
Thank you Nasko,
We were already trying to rely on the DragDropCompleted() hook in our CustomScheduleViewDragDropBehavior but I was just testing if state.DestinationSlots was null to not call base.DragDropCompleted(state)
Now I realize this state.DestinationSlots is actually never null, and above all it seems we should just never call that base.DragDropCompleted() as you invite us (I confirm it does not harm any of our expected case).
At the end of the day I am a bit perplex about the point of calling base.DragDropCompleted(), and about the real point of the DragDropCompleted() method.
<Doc just says>
DragDropCompleted( DragDropState state) - This method is called when the drag-drop operation is finished.
</Doc just says>
At first sight, it gives the impression to be the place to catch that a DragDrop action has completed to notify something, but not to disable a default behaviour like a drop outside. Don’t you agree?
The main purpose on the DragDropCompleted method is to delete the item from the source collection which should be used when you have scenarios such us drag and drop between RadListBox and RadScheduleView. Calling the base implementation the DragDropCompleted is where the appointment is removed from the source collection. Because of that for your concrete scenario and based on the provided description we suggested the DragDropCompleted's base called to be removed.
We hope the provided information for the DragDropCompleted will be helpful for you.
Thank again very much Nasko. It's much easier when one knows the purpose of this standard DragDropCompleted method. With your help it crystal clear indeed. (a quick search on the web does not provide something as good)
Now, with my colleague, thinking on how long we have spent on this issue (we won't dare to think too long about it), and how simple the solution is... we just wish the doc would have said in first place something as good as you explain on this forum. Indeed, as said in my previous entry, what the doc says currently looks a bit like a typical documentation point "click on the Button Cancel to cancel" or "Click on Validate to Validate" ...
May I kindly suggest to improve the documentation about this method with what you just said?
I am glad that the provided information helped you to understand the proposed in my previous response approach. As for the documentation indeed you are right and the provided information is not sufficient enough and we will definitely consider to improve it.
If you have any additional questions or concerns regarding Telerik controls, please do not hesitate to contact us.