I've got an issue where I can drag/drop in the Dock Manager between the document host and the content panes using the DragDrop framework. But when a content pane comes out into a separate window, all of a sudden the DragDrop framework refuses to recognize it as a drop target.
Is there a known issue with the DragDrop framework that says it doesn't support multiple windows (dragging from one window to another)? Or is there something subtle going on in the xamDockManager that is interfering with the behavior of drag/drop?
Any help would be appreciated. I found an extremely dated article that says drag/dropping between different xamDockManagers is not supported. But we are only using one, with a content pane that is floating:
http://www.infragistics.com/community/forums/p/17937/65183.aspx#65183
Please let me know. I can also try to create a repro if needed.
That other article is even less applicable than I thought. Please ignore it.
Sorry, can someone move this to a new group? It should be under the DragDrop Framework since it isn't specifically about the xamDockManager (as it turns out).
It just so happened that the xamDockManager was hosted in a Windows Forms ElementHost. Then when the content pane was broken out, it was hosted in a pure WPF window.
The problem appears to be a more general issue with the DragDrop framework not working between a WinForms Element Host and WPF window targets.
Repro:
- Start with Infragistics WPF samples (look for "BasicDragDrop")
- BasicDragDrop converted to a simple user control and hosted in Windows Forms ElementHost
- Programmatically open a separate, standalone (modeless) WPF window (eg. attached is StackPanelWindow)
- Run the sample. Open the window. Try to drag from the BasicDragDrop in the ElementHost out to the StackPanelWindow. This fails.
This repro turned out slightly different than I originally thought. The ElementHost normally gives me few issues but when the dock manager's content pane was pulled out of it, dragdrop stopped working.
Thanks in advance. David
Case number is CAS-155149-R6S2V5 .
Hello dbeavon,
Thank you for your post.
I have reproduced this behavior that you are seeing using the reproduction steps that you have provided. I am currently investigating further into this issue to see what can be done to allow dragging between the ElementHost WindowsForms form and the WPF Window. I should have more information for you on this matter shortly.
Sincerely,AndrewAssociate DeveloperInfragistics Inc.www.infragistics.com/support
I have been investigating this issue further, and it appears that drag drop functionality works in every scenario here except for WindowsForms window to WPF Window. The opposite (WPF Window to WindowsForms host) works correctly. This is unexpected behavior, and as such I have asked our engineering staff to examine this further. To ensure that this issue receives attention, I have logged it in our internal tracking system with a development ID of 193574.
I will be linking this development issue to the case that you have with me that discusses this issue. That case has an ID of CAS-155149-R6S2V5.
Please let me know if you have any other questions or concerns on this matter.
Thank you for helping me take a closer look. I am especially eager to find a way to move forward, even if it means using a workaround. If there are any workarounds that you can come up with, please let me know. For example, maybe I could detect when the dragging leaves the original ElementHost and programmatically begin a new WPF-only drag/drop operation. I'm open to any and all ideas.
I am not sure of a way that you can end one drag-drop operation and begin a new one with the Infragistics drag-drop framework, but as a workaround I would recommend that you use the built-in WPF DragDrop class. This class has a static method named DoDragDrop, in which you can pass the element you are trying to drag from the WindowsForms Element Host to the WPF Window. Keep in mind, you will need to end the current Infragistics drag drop operation if you decide to do this, or you will have multiple drag-drop operations going on at the same time.
I have attached a sample application that demonstrates this. In the sample, I handle the DragSource.DragStart event, and cancel it by setting e.Cancel = true where e is the event arguments object. Before cancelling though, I call the DragDrop.DoDragDrop method on the Label that is being dragged in my sample. In the WPF-only window, the StackPanel has its AllowDrop property set to True, and by handling the Drop event on it, you can add the Label to the StackPanel that way.
I hope this will provide you with a viable workaround while we look into this development issue on our end. Please let me know if you have any other questions or concerns on this matter.
I finally had a chance to look at this. I was out of the office for the Microsoft Ignite conference.
For a minute I thought your example was showing that the IG DragDrop framework was interoperating correctly with the built-in WPF DragDrop class.... that was not the case.
I hate to sound negative, but the workaround is confusing as it decorates the markup with the dragdrop implementation from two unrelated frameworks. Also, I would need to do extensive work to rewrite the parts of the programs that currently rely on the DragSource class (in particular I use the mouse cursors and the events DragSource.DragStart which changes the DragSnapshotElement, and DragSource.DragOver/DragLeave give visual cues when the user is about to perform the operation on the target.)
Can you suggest a workaround that leverages more of your IG DragSource? For example, maybe I can use reflection to invoke DragDropManager methods to cancel old ones and start new dragging operations, eg:
InfragisticsWPF4.DragDrop.v14.1.dll!Infragistics.DragDrop.DragDropManager.OnDragStart() orInfragisticsWPF4.DragDrop.v14.1.dll!Infragistics.DragDrop.DragDropManager.OnMouseMove()
I can't imagine using Reflection would be harder to read or be less supportable than layering two dragdrop frameworks on top of each other. Any thoughts would be appreciated. Or perhaps the developers are able to find a root cause that we can address in a more direct manner?
Thanks David
I have been discussing this issue with my colleagues and it doesn't appear that there is any built in way to start a drag-drop operation programmatically with the Infragistics drag-drop framework. This framework was designed to let a user mark elements as drag sources and drag targets and let the source code of the framework do the rest. For the time being, I would recommend that you use the workaround that I have provided you while development issue 193574 undergoes review.
If you would like to see a way to programmatically being a drag-drop operation possibly included in a future version, consider placing a new product idea at http://ideas.infragistics.com.
Was fixed in 2015.1 SR 2055 released June 2015.