FoxPro Programming
Support for Blazor Pages within VFP
Gravatar is a globally recognized avatar based on your email address. Support for Blazor Pages within VFP
  Steve
  All
  Mar 4, 2020 @ 03:51am

I have been tasked with getting a website using Blazor integrated into a legacy VFP application. This presents a problem due to the fact that IE11 isn't a supported browser for Blazor. Therefore I can't use the good old Microsoft Web Browser ActiveX control (IEFrame.dll).

I've looked at a way of launching another browser (Chrome) and then using the SetParent and SetWindowPos Windows API functions to tie the browser window into the VFP application. This seems to work but how can I get event notifications, or navigate to a new URL afterwards? I'm aware of BINDEVENT() and EVENTHANDLER() but I can't see that they will give me what I need.

Ideally I would use a replacement ActiveX that has the same / similar interface to IEFrame.dll that supports other browsers (Chrome or Microsoft Edge will do).

Has anyone used https://www.webkitx.com/ or know of a better solution?

Thanks

Gravatar is a globally recognized avatar based on your email address. re: Support for Blazor Pages within VFP
  Rick Strahl
  Steve
  Mar 4, 2020 @ 01:30pm

Yes IE doesn't support WebAssembly (assuming you're planning on using the client side version of Blazor rather than the server side version). The server side version probably would work.

Chromium based (or the one Gecko based one) alternatives controls for FoxPro are all bad. Or at least were a few years ago. The problem is that these things need very tight ActiveX integration and FoxPro doesn't have all the interfaces required to make this work so a lot of these controls have some small but important missing features that cause the controls to be unstable. Also - those non-IE based browsers can't interact with the document via COM as the IE control can, so even if you get it hosted and documents loaded, interaction with the page involves other mechanisms (usually some special messaging API provided by the lib) to interact with the page content.

One way that might be be possible is to interact with an external browser via Web Sockets. If you control the server side code you can inject a small bootstrapper that acts as a messaging service that lets you send messages back and forth between your FoxPro app and the browser. For Web Socket support in FoxPro you can tap into .NET either using native Web sockets or more likely using SignalR. I've done this a few years back in a SwFox session (not for browser automation, but for real time communication in both Web and Desktop apps and used the Web Browser control for the FoxPro client and that worked fine. It's not trivial but doable.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: Support for Blazor Pages within VFP
  Steve
  Rick Strahl
  Mar 5, 2020 @ 01:37am

Thanks Rick - very insightful as ever. Some things I wasn't even aware of (Gecko) and the SignalR repo is especially interesting for me. And "Yes", we do control the serverside code (I'm writing it). Unfortunately a core requirement is that the pages are hosted within the main VFP application, so...

For the benefit of others I found another reference to WebKitX (https://www.webkitx.com/) on this messageboard (https://support.west-wind.com/Thread5M90RPQDA.wwt) and for now at least it has got me out of an immediate hole. I was particularly pleased with the VFP references on the site (See: https://www.webkitx.com/doc/light/Getting%20Started%20with%20FoxPro%209.html) which are all too rare these days although it isn't officially "supported". The event hooks are granular enough for what I need and I would encourage others to take a look. There is support for controlling the DOM and listening to DOM events!

This seems to work just fine and I've even run some fairly rigorous testing on it. The site in question is internal with around 1000 users so those are the numbers I've simulated. Granted it's not very high throughput but non-the-less looking good so far.

Thanks, Steve

Gravatar is a globally recognized avatar based on your email address. re: Support for Blazor Pages within VFP
  Rick Strahl
  Steve
  Mar 5, 2020 @ 01:48am

Interesting - I hadn't seen that one before.

This uses the standard CEF Chromium engine. There are also open source implementations around this. I've used CEFSharp before but had quite a few issues both in performance and stability, but as I said that was a few years back. Maybe it's more stable now.

The big issues at the time for me were the huge runtime requirement (20+ megs additional packed content which was more than twice the size of the entire packaged app 😃

The messaging is standard CEF messaging using a message interchange protocol that they have built in. Basically involves pushing strings (JSON most likely) back and forth for interaction. I built a prototype using CEFSharp for Markdown Monster in .NET and got it all working but he perf was just too slow. But then that app is running a complex editor in JavaScript so the back and forth messaging overhead was killing it.

Let us know how this goes. I'm curious and would be interested to see if this works stably in the long term.

Gravatar is a globally recognized avatar based on your email address. re: Support for Blazor Pages within VFP
  Steve
  Rick Strahl
  Mar 5, 2020 @ 02:27am

I haven't really looked at CEFSharp but is it redundant with the introduction of WebView2?

Deployment: You're right; The total deployment of WebKitX to clients as suggested runs to 166mb! Ouch. The main culprit is libcef.dll which is 86mb alone. You can reduce the deployment size to 149mb by excluding Flash support, but it's still a huge deployment.

Gravatar is a globally recognized avatar based on your email address. re: Support for Blazor Pages within VFP
  Rick Strahl
  Steve
  Mar 5, 2020 @ 11:40am

WebView2 isn't ready for .NET yet - only a C++ component so far. And given how that looks I think it'll be some time before WebView2 that's Chromium based will be stable. The existing WebView2 using the Edge browser is a non-starter because classic Edge (non-Chromium) is dead so certainly don't want to muck with that tech and Edge had terrible inconsistencies with latest HTML specs.

I'm hopeful that the Chromium based WebView2 will be usable - I really have a need for that for several apps (Markdown Monster mainly). I've spoken at length with some folks at Microsoft about this and while they talk a good game the results so far have been underwhelming. That was nearly 2 years ago and little has changed since then other than they actually released the Chromium Edge into general release at the end of last year. Clearly that was the first priority, but Microsoft doesn't see the app integration part as important enough to throw dev resources at it.

I do really hope this will work because it solves a number of issues that CefSharp (and other controls have) - namely removing the requirement for the huge distribution as long as Edge Chromium is installed and some of the performance and airspace issues that the other controls have.

+++ Rick ---

© 1996-2020