I understand that there are layout considerations for using a Windows Forms host in a WPF control like XamDockManager, but I'm wondering what can be done to cope with them.
For example, if I have a Windows Forms WebBrowser control in a ContentPane "W" and a System.Windows.Controls.Button in ContentPane "B". If I try to dock "B" on "W", I don't see the dock indicators since the Windows Forms control on "W" is top most.
Is the best thing I can do is to detect when a drag is occuring and then take a snapshot of the Windows Forms control and then temporarily switch it to a WPF based bitmap so that the docking indicators can go on top?
Any further guidance?
Thanks!
If the xamDockManager is hosted within a WPF Windows application then the indicators would be shown in a top level window so it shouldn't be underneath the WinForms control. Is it possible that you're doing this in an XBAP or AddIn model?
I'm porting a (CAB based) Windows Forms app to WPF in stages. I still have a Winforms shell. Right now we have a mix of WPF and Winforms based modules.
We were using UltraWinDock but noticed a sizable memory tax for each ElementHost for the cases where we hosted WPF views. My thinking was that the tax of hosting Winforms in WPF would be less than the reverse and our newer WPF based views would be tax-free.
Any guidance for this scenario?
Thanks again!
So just to clarify, you have a WinForms Form that contains a xamDockManager (within an ElementHost) which then contains HwndHosts (in your case a WindowsFormsHost which contains the WinForms WebBrowser)? At least with the current version, if the xamDockManager is not hosted within (and able to get to) the WPF Window, all of its floating windows (docking indicators, drop preview and floating panes) will be hosted within the xamDockManager (or the root wpf element). That means you will not be able to drag the floating windows outside its bounds and is also why you are seeing the docking indicators be overlayed by the Windows Forms control.
You are correct on your clarification.
It looks like the best approach is to remove some of the CAB stuff that depended on a WinForms based shell (something we've avoided, but it's probably best long term).
Thanks for your quick response!