Flawed Docking behaviour using WebBrowser in DocumentWindow - Docking/MDI for WPF Forum

Posted 16 years ago by Andreas Heil - Germany

Version: 9.1.0501

Hello,

I observed a flawed docking behaviour when using a WebBroser control as content of a DocumentWindow.

I was able to observe the following issues:

1. When opening a new DocumentWindow containing a WebBrowser control, the DockSite.WindowActivated event is fired, also the DockSite.WindowDeactivated event is fired if another DocumentWindow was opened before (not containing a WebBrowser control).

2. When switching back to the previously selected DocumentWindow, the DockSite.WindowActivated event is fired, however, the DockSite.WindowDeactivated event is not fired for the DocumentWindow containing the WebBrowser control.

3. When switching back to the DocumentWindow which contains the WebBrowser control, none of the both events is fired.

Consequently, the DockSite.LastActiveWindow property never returns the DocumentWindow containing the WebBrowser control.

While this occures while being in tabbed mode, another observation was made when using tiled mode. When selecting the DocumentWindow containg the WebBrowser control, the tab is not highlighted (eg. the text of the tab is not in bold). Also none of the events is fired.

Is this a known issue with the WebBrowser control?

Many thanks,
Andreas

Comments (2)

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Andreas,

Thanks for writing. If you could email over a simple sample project that shows the events and LastActiveWindow property issues that would be helpful so we can debug it.

I think the main problem here is likely due to focus. The WebBrowser is really doing interop and doesn't properly raise WPF focus events. So when we are doing things like looking to see if a new docking window gets focus and raising activated/deactivated events based on that, we are probably never getting the events we look for since WPF is not properly raising them (due to interop issues). If you can email over a repro we can see if there is something additional we can do to force changes without having to look for focus changes.

Actipro Software Support

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Andreas,

We have fixed this issue for the next maintenance release. The underlying problem is that the WebBrowser control does not raise the PreviewGotKeyboardFocus event, when MoveFocus(First) is called on it's parent element (i.e. the UserControl). Our update attempts to find the first focusable child element and call the Focus method directly, and only use the MoveFocus method as a last resort.

Actipro Software Support

The latest build of this product (v24.1.5) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.