fpcefsharp browser 1

Yes, we are using it. Here at Christof Wollenhaupt's GitHub:
FYI, lots of redistributables. Also requires VC++ 2019 runtimes.

The "recording of my session" link on Christofs Github page actually is you cut off the 4.

It surely isn't that easy to set up and he explains how updates to new versions also need updates of runtimes and recompilation of fpDotNetContainer. That makes it problematic, if you take the latest version of the project and want to integrate it in VFP, that requires a lot of dependencies to recompile so they are all in the same boat, the same dotnet runtime version.

I tried the Quickstart and also failed for now.

1. Download the Zip of one version, unzip that anywhere.
2. Follow the instruction:

Christof Wollenhaupt said:

The fpDotNet folder contains a COM control that you need to register. It contains a CMD file that you can execute as an administrator.

Click to expand...

So far, so good. I started cmd.exe in administrator mode and CD into the fpDotNet folder and executed the register.cmd, which gives me some warnings about unsigned assemblies and the advice to change to a strong name. But it registered and gave the tld file.

The showhtml.scx didn't load and said there is an unregistered ole control in record 7, which is removed.

I had to manually add the fpdotnet container to a new form once to get this going, so create a new form, put an Ole Control on it, you're then prompted for which Ole control and find the fpDotNet.DotNetContainer control in the list.

After I did this once, I could then also modifiy the showhtml.scx with that container on it. But starting this I get an OLE error about conversion of an object of type System.DBNull to an object of type System.Windows.Forms.Controls and I think that could be due to version mismatch of the dotnet runtimes or some strict type conversion policy that could be changed to allow such conversions. But how and where? I don't know yet.

My 2 cents on this: I already talked about the WebKit Active X Christof also mentions. He gave the motivation to avoid ActiveX dependencies, but his fpDotNet Container also needs registration and the cefSharp Brwoser Control overall has a more complicated handling. I would say investing a couple of hours I could also instead invest a couple of bucks. Sure, the ActiveX mentioned is more expensive than VFP was, but my time also has some value.

I see some things that he talks about I don't find at first glance in the Webkit ActiveX, like WebRTC. But it does also not surprise me to stumble upon hurdles Christof was unable to see, even if he tested his Quickstart guide on a computer in the same state as one of ours, just with Windows and VFP installed and without Visual Studio. So I guess the 2 years that passed already made that difference to the available framework versions and mismatches.

But maybe it is actually as easy as installing VS 2019 community edition to get this working for my development PC, if not by recompiling everything from sources. I'd just like to have a simpler redistribution solution.

Chriss

PS: 5 minutes later it works to DO FORM showhtml.scx WITH " the System.DBNull was actually due to no given Config and that due to non given Url.
PPS: It takes quite some time before the first render of anything, alsmot unbearable.

Hi Chris,

Thank you so much for the update.
I think pursuing this path is a difficult task as the dependencies are hard to resolve and installing on different environments and computers present a big hurdle.
I tried to play around with it, it works on my laptop but when I tried to install elsewhere I got errors and issues with it.

Thank you for your reply.
Cheers,
Joy

In all fairness, Christof tells how many Windows versions back to Vista have the necessary dotnet version. But that requirement shifts when CEF shifts it. I'd be fine if it "only" supports Win10 and 11, I don't see the biggest problem there other than not having control over it.

What's bothering me is, that I had to once create a form from scratch so VFP was able to modify and run a form with Christofs fpDotNetContainer, that's actually in his hands and may also have been a glitch of the registration that a restart of Windows would have fixed, too.

The need for registration also exists with any ActiveX and is solvable with a setup. What would be a honorable thing to do is wrap it up as ActiveX, which Christof says he wants to avoid. The way his fpdotNetContainer is working still also is the core of ActiveX, the Ole/COM interface.

A thing that's not working as automatic as with the old SHDocVw.dll based Webbrowser control is upgrades, of course. And you want to stay up to date with security patches, as the same vulnerabilities apply to a fully featured Brwoser and embedded Webbrowser, especially when not just hosting your own WebApp "domain".

And what remains, as far as I understand it is that the chromium code base takes a longwinded and complex initialization. It also takes a while for the Chrome browser to start. I think if Chrome is your default browser and installed as the full Google Browser product, it uses some mechanisms to speed up this start. I think GoogleCrashHandler.exe and its 64bit versions are started with Windows, maybe even a first Chrome.exe process, so some parts are already up and running.

The question is: What else could work? There are mainly 3 notable browser engines: Webkit (Apple Safari, originated in KDE), Chromium/Blink, and Gecko. I'm not into all of this as deep as I'd like to give any knowledgable recommendation, but I see CEF isn't Chromium, Chromium itself is a C++ MFC/ATL project, see By its name CEF as Chromium Embedded Framework is designed to simplify embedding of Chromium based browsers, which I think is the stronger reason to choose it than pulling it into the direction of dotNet.

Mono.Webbrowser - also dotNet - interestingly chooses to integrate both WebKit and Gecko:
There surely are simpler things like HTML render engines that don't try to be a fully fledged embedded browsers, but since JS is in it and cryptography and video/audio codecs, WebGL, webRTC and more, I think such things can only give limited support for some but not all aspects you'd like a WebBrowser control to do in your application.

Chriss

fpCefSharp is not for everyone. But there are specific use cases for it. We have a customer who is hosting their own Jitsi-Meet video conferencing service. For those that don't know, Jitsi-Meet is a huge open source project (on GitHub) for video conferencing that rivals Zoom. Our customer wanted to add access to their hosted Jitsi to an existing VFP app of ours. Since Jitsi works best with Chromium-based browsers, we decided to give fpCefSharp a shot a few months ago. It has become a huge success with over 50 user installations for our customer (and growing).

While some technology implementations are difficult, rarely are they impossible. To make blanket comments without the experience of implementation is both irresponsible and short sighted. It's better to say "I really don't know. I don't have much experience with that.