|
|
Rank: Newbie
Groups: Member
Joined: 10/20/2015
Posts: 2
|
We bought the EO browser to use in a WPF application. It does not work well with a third party control that handles the layout of the app. We have fly-out panels that need to display over the EO WPF Browser control. The EO browser is displaying over the fly-out panels. After submitting a support ticket to them, they say the EO browser contains a WinForm control
" It looks like the EO WebBrowser control contains a WinForms control. If so, the current behavior is expected - all WinForms controls are always rendered under the WPF content. "
Is this true? Is there a way to use the WPF EO browser without a WinForm control? Is there a property that can be set?
Here is how the browser is set up in our code.
<eo:WebControl HorizontalAlignment="Stretch" VerticalAlignment="Stretch" Grid.Row="0"
Visibility="Visible"
Panel.ZIndex="0">
<eo:WebControl.WebView>
<eo:WebView x:Name="ChartWebViewControl" >
</eo:WebView>
</eo:WebControl.WebView>
</eo:WebControl>
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,225
|
Hi,
This does not have anything to do with WindowsForm controls. It has to do with window handle. The core EO.WebBrowser component does not rely on either Windows Forms or WPF. But it uses its own window handle. As such the WebView is a child window of your main window.
In a WPF application, you can not have child element of a parent window to be stacked above a child window. This is a known issue of WPF and it is called "airspace issue". You can search online and you should be able to find plenty of information on this issue ---- there are various workaround that have been discussed, but as far as we know there is no simple clean solution. Since this is a WPF limiation that applies to all control that has its own window handle, you will run into the same issue with any other control that uses its own window handle as well. I believe MS's own IE based WebBrowser control uses its own window handle as well, so it would also have this issue. So you may want to change your application design to avoid this issue.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 7/6/2017
Posts: 2
|
We just purchased this product for use in our WPF application and are seeing the same exact issue. We've purchased the EO browser to replace a no longer supported Awesomium browser (also based on Chromium) and I just want to point out that that product did not have this issue.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,225
|
MGorsuch wrote:We just purchased this product for use in our WPF application and are seeing the same exact issue. We've purchased the EO browser to replace a no longer supported Awesomium browser (also based on Chromium) and I just want to point out that that product did not have this issue. Hi, Thank you very much for your feedback. We have looked into this and there is no clean way around this issue if you use WPF. It's a well known WPF issue. We update to Chromium rather frequently so that we can stay up to date. We do not know the implementation detail of Awesomium but one reason that they can do could be that they completely changed the rendering layer. This is not doable with more up to date version of Chromium browser engine due to a number of factors, such as the complexity of the rendering engine and the fact that the engine must interact with hardware acceleration interface directly (in order to support modern features such as WebGL), thus by passing WPF rendering pipeline. This is probably why Awesomium is no longer supported. Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 7/6/2017
Posts: 2
|
Ok thanks. That at least helps with justifying a redesign.
|
|