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?

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 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.aspx

Note: 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.


 

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.