Occurs when the input system reports an underlying drag event with this element as the origin.
Assembly: System.Windows (in System.Windows.dll)
Do not attempt to access the data object payload from event data (DragEventArgs.Data) when handling this event. Although several drag-related events share this event data type in their handler delegate, only a Drop event occurrence provides a useful DragEventArgs.Data value. For more information, see DragEventArgs.Data.
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
is a bubbling event. This means that if multiple 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 occurrence might be marked as handled through an OnDragLeave 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 , because no RoutedEvent identifier for 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.
For a list of the operating systems and browsers that are supported by Silverlight, see Supported Operating Systems and Browsers.