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.
Hi Andrew,
I encountered the similar problem which is explained inside the error report (CAS-12213-APH13G). The DocumentHost becomes hardly usable when putting Winforms content inside. I posted request 2 days ago and it's still 'waiting assignment'. Moreover, I didn't see any solution to the problem neither among the bug reports nor inside the forum. One of our developers even reported me that similar strange behavior ( tab selection 'jumps' back) was noticed without winform inside.
Thanks.
Tech support can check on the status of the issue but I can tell you that this issue (at least based on the description) is the same as several others reported and should be addressed in this next hotfix which should be available shortly. Since you've reported the issue you should be notified when the hotfix is available. The issue about focus shifting back is related since the ActivePane is based on the focused element but when using an HwndHost (WindowsFormsHost, WebBrowser, Frame with web url, AddInHost, etc) all are HwndHost based and when they receive focus keyboard focus is taken out of the WPF hwnd. In any case that aspect should be handled in the hotfix as well.
That is, currently I can only regret that this information was not published as a control limitation...
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.
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.
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.
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.