I'm using xamDockManager in my WPF application but I need to use a webbrowser control. So in my DocumentContentHost I have a WidowsFormsHost wrapping the WinForms webbrowser control. This all works fine except for when I have an unpinned dock panel. The panel pops out when I move the mouse over the header but the panel draws behind the webbrowser. If I pin the panel the the webbrowser is correctly resized and everything is fine. It's just when the dock panel is in the unpinned state that it appears behind. Any way I can fix this or will I have to go the the beta WPF webbrowser?
Thanks,
Adam
I am doing exactly the same thing and running into the exact same problem.
Webbrowser control wrapped in WindowsFormsHost control, hosted by DocumentContentHost. When unpinned and hidden panel files out, it sildes behind the Webbrowser control.
This is slightly different than the issue to which I was referring. This happens because the flyout panel is not hosted within a separate window and therefore all the elements (the xdm and the flyoutpanel) are hosted within the same os window whereas the webbrowsercontrol is in its own child window. You should report this issue to the support group. We'll probably have to add an option to have the flyout panel hosted within a popup since there are limitations to how a popup can be used - e.g. it will adjust its own position such that it never renders across screens.
I have reported this via support. Here is the response (hope you dont mind me posting it, but thought it may help others):
It is expected that the control(s) on a WindowsFormsHost will be drawn over the fly out for the SplitPane when the pane is collapsed. This is due to the ‘airspace problem’ that you referenced when you logged the case.Since the WindowsFormsHost will create a separate HWND, it will draw over any WPF elements on the Window containing the WindowsFormsHost. This information is available in the “Layout Considerations for the WindowsFormsHost Element” on MSDN:http://msdn.microsoft.com/en-us/library/ms744952.aspxNote: The above link isn’t owned or maintained by Infragistics.
The drop down for the application menu of the XamRibbon will appear over controls hosted in a WindowsFormsHost because the drop down is actually another HWND which doesn’t cause an airspace violation like the XamDockManager and the WindowsFormsHost.If you can create another HWND where the fly out of the SplitPane is, you may be able to work around this issue. This would either be done by modifying the Templates for the XamDockManager and possibly using a Popup of by responding to the mouse over of the tab for the fly out and then showing a Popup then instead. I am not sure about the implementation details of either of these or if they are even feasible.
The response is correct in explaining why it is happening and as mentioned in the referenced link, it is an expected behavior that windowsformshost will appear over other elements. That being said, it is feasible for us to workaround the issue with regards to the flyout panel since we are creating it in code and there is an understandable expectation that the flyout panel's contents be displayed above other elements in the window - including a WindowsFormsHost. As I mentioned there will be ramifications/limitations (and there could be others - e.g. animations may not be as smooth, etc.) to doing this so likely we would have to do this as an option (i.e. add a property). I would recommend replying back about this issue and request it be reopened/reviewed.
I have the simmilar problem.
I have few WidnowsFormsHost tabs with Wpf tabs and when i switch between tabs, tab switching does not work properly i.e. WindowsFormsHost does not let WPF controls to come at front.
Is there any workaround for that?
I believe the issue has been reported but you should report the issue to the support group so you can be notified when a fix is available.
Hi Vince,
I recently added a problem scenario to the described CPU time issue and opened a new support request for the ContentPane Header problem.
Thanks.
Alexy,
I've taken a look at the two support cases you've mentioned, and I've asked my staff to handle both cases on an escalated basis. We'll send you further updates through the cases themselves. You should expect to receive an update for both cases by the end of the US work day today.
alexeyk said:3. Another issue that I have talked about is the following (non fatal): The dock manager fails with exception when inserting wpf control as content pane header (without using datatemplate).
Please submit a separate support request for this issue. If possible, please attach a sample project that we can run and debug that reproduces the behavior you're describing, because this will greatly speed our research and thus will help us to get you a resolution more quickly.
Hi Andrew,
The meaning is that we have encountered some 'fatal' problems while using the xamDockManager with Windows Forms controls inside:
1. The issue I've been talking about is in development since 12.12.08 without any response since then (CAS-12213-APH13G)
2. I've opened a new (also 'fatal') issue (CAS-14100-LPQVWQ): suppose there's tabgrouppane with 2 tabs with winforms inside. After I move from one tab to another and focus on winforms control, the application begins to 'eat' the CPU (50% cpu for dual core). It stops doing that when I click outside the winform control.It seems that the focus 'jumps' between the 2 windows handles (according to profiler), but I'm not sure. This issue has not even been assigned yet.
3. Another issue that I have talked about is the following (non fatal): The dock manager fails with exception when inserting wpf control as content pane header (without using datatemplate).
As a result we currently stand before the decision to leave the component in case we don't get some quick fix, as we do not get the expected profit from the component.
I think such common integration scenario (winform inside wpf) should have been tested or there should have been some limitations disclaimer.
I'm not sure I follow - if we were aware of the issue we would have made efforts to address it before release or post it in the known limitations section of the help but as it was we were not made aware of the issue until recently. It should be noted that there are several limitations of using HwndHosts (which includes WindowsFormsHost) in WPF that are documented in MS' help here: http://msdn.microsoft.com/en-us/library/ms744952.aspx. These still apply as they are general WPF-interop limitations.
That is, currently I can only regret that this information was not published as a control limitation...