Microsoft Silverlight will reach end of support after October 2021. Learn more.
Occurs when the input system reports an underlying drop event with this element as the drop target.
Assembly: System.Windows (in System.Windows.dll)
'Declaration Public Event Drop As DragEventHandler
public event DragEventHandler Drop
When Drop occurs, you are typically interested in the value of DragEventArgs.Data from the DragEventArgs event data. If a file list payload was dropped, then Data contains file list information. The information is in a particular system-specific format. One possible technique for using the data is casting it as an array of String. More advanced scenarios may want to work with an array of FileInfo. For more information, see GetData(String).
Drag-and-drop events in Silverlight support a scenario of enabling a Silverlight UIElement to be a drop target for a file list that is dragged from another area of user interface for the overall platform/operating system. The drag origin can be outside of the Silverlight content area or the browser host. True drag-and-drop support that involves carrying a data payload from one object to another is limited to this particular scenario in Silverlight. However, you can enable related scenarios that stay within the Silverlight content area by using mouse capture, and transmitting your own data or using event data from the mouse events, and then adjusting object layout properties. For more information on how to use mouse capture in this way, see How to: Drag and Drop Objects in UI Layout. You also potentially can use HTML bridge techniques to work with a browser host's HTML DOM input events, for objects (including Silverlight) rendered in the browser host's content area. For more information, see HTML Bridge: Interaction Between HTML and Managed Code.
Routed Event Behavior
Drop is a bubbling event. This means that if multiple Drop event handlers are registered for a sequence of objects connected by parent-child relationships in the object tree, the event is potentially received by each object in that relationship. The bubbling metaphor indicates that the event starts at the source object that received input stimulus, and works its way up the object tree. For a bubbling event, the sender available to the event handler identifies the object where the event is handled, not necessarily the object that actually received the input condition that initiated the event. To get the object that initiated the event, use the OriginalSource value of the event's RoutedEventArgs event data. For more information about routed event concepts, see Events Overview for Silverlight.
Setting DragEventArgs.Handled in the event data prevents handlers from acting, and effectively ends the event route for most scenarios. A Drop occurrence might be marked as handled through an OnDrop override in a specific control, rather than through an instance handler in your application. You cannot use the AddHandler technique for handling already-handled occurrences of Drop, because no RoutedEvent identifier for Drop is available in the public API.
For either platform, you cannot handle the UIElement drag-and-drop events while running in full-screen mode, or in windowless mode. For more information, see FullScreen (Silverlight Plug-in Object) or Windowless (Silverlight Plug-in Object).
Drag-Drop, UAC, and Privilege Boundaries
When developing and debugging applications that use the drag-and-drop events, make sure that all participating processes (Visual Studio, the browser host, and the file list that provides the payload) are running at the same privilege level. On systems that use User Account Control (UAC), messages across lower-to-higher privilege boundaries might be suppressed, and this might prevent the Silverlight drag-and-drop events from being raised or debugged.
Supported in: 5, 4
For a list of the operating systems and browsers that are supported by Silverlight, see Supported Operating Systems and Browsers.