Welcome Guest Search | Active Topics | Sign In | Register

Z-Index of EO.Webbrowser Options
Michael
Posted: Tuesday, August 15, 2023 6:30:04 AM
Rank: Newbie
Groups: Member

Joined: 8/15/2023
Posts: 1
Hello,

we are currently in the process of converting an existing WPF application into an Angular application.

For this reason we want to integrate new Angular parts into our WPF application.

We have noticed that there seems to be a fundamental problem with web browser controls under WPF. The EO browser control do not adhere to the Z-index within the WPF application.

As soon as we display Angular applications using the EO web browser and we try to display WPF parts over it, it fails. The EO web browser always stays in the foreground even though the Z-Index settings are correct.

Can you provide us with a reliable (!) solution to this problem? We are basically enthusiastic about the EO Webbrowser and would gladly buy it if we could get this problem under control.

We have already experimented successfully with CEF-Sharp in the last few days, but we have to ship C++ libraries for this, which we would like to avoid. We would rather go the convenient way with EO.

We would really appreciate if you could help us in this regard.

Regards

Michael
eo_support
Posted: Tuesday, August 15, 2023 10:16:58 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
Hi,

This is a known limitation with WPF and we are not aware of any simple workaround for this issue. You can search for "WPF airspace" online and you should be able to find plenty of information and possible workaround on this issue.

The root of the problem is a regular WPF control CAN NOT render over a child window. Most WPF controls are lightweight windowless controls so they are rendered as part of the containing Window object, which manages z-index among all child controls. However in case a child control has its own window handle, it "carves" out a portion of the parent Window object's surface and declare that portion as his own "airspace", which child controls of the parent Window object can no longer occupy. This in turn makes it impossible for the "regular" windowless child controls to be rendered above the windowed child control.

EO.WebBrowser is based on Chromium browser engine which does use its own window handle, so it triggers this issue. We are not aware how CefSharp can workaround this issue since it's based on the same Chromium browser engine, so it should be subjected to the same limitation. However if you can send us a sample project we will be very happy to look into it and see what we can find. You can send files to us through our contact us page:

https://www.essentialobjects.com/contact

Please do not include CefSharp binaries since we can download it directly.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.