>On the activeX side you have a few compontents in dll:
>MsHTML.Dll for Dom, each HTML control, SVG and a few other tidbits
>ShDocVw.Dll/tlb for WebBrowser and InternetExplorer.Application plus a few shell interfaces
>also
>MsHtmlED.Dll IIRC the old Editing option I never had running without problems
>MsHtmlDac.Dll probably some data access
>MsHtmlMedia.Dll - to import Media Players

Why do you care? These are Windows system components that live in a system installed location. They will always be there - you don't need to install any of that.

>Why fidlle at all with it, just leave the program files\Internet Explorer\ directory alone ?
>As long as ShDocVw.Dll is unchanged, a 2 liner

>loIE = CREATEOBJECT("internetexplorer.application")
>loiE.Visible = .t.

>will run the old IE ?

Because it doesn't give you integration into your app. It's a separate window that you can't easily interact with - you can't easily handle events because it's not an activeX control etc. etc. There's lots of reason why you want an **embedded** control in form. Internet Explorer relies on those same components plus some additional ones to manage the host shell.

And most likely that COM object will cease to work, because that actually launches Internet Explorer which will be removed from Windows by default.

>My last DOM tweakings were not made from external objects calling into Trident interfaces, but Javascript functions / objects injected into DOM (calling those interfaces if no direct Javascript call was available)- worked in Trident and pretty certain will work in Chromium if then delegating to W3C DOM interfaces. With a bit of wrapping a common interface for WebBrowser/MSHtml, WebView2(Chromium) and WebDriver(Selenium) should be possible - at least until I find something smarter ;-)

The problem is that the new Chromium controls don't have ActiveX interfaces. And those that do (I think CEF Sharp does) it's still a bear to integrate, plus you have to ship the huge browser runtimes (separate from whatever browser is installed).

Unless you have application integration, none of this help you if you need to access the data from your host application. For example, look at something like Help Builder that uses a FoxPro application to automate a JavaScript based editor or generates output and then renders it in a browser using scripted layout templates. There are probably 100 or so function calls that go from FoxPro into the DOM. Like retrieving and setting the document, setting focus, grabbing selections, setting content in selections, inserting links etc. While it's possible to build an entire UI in JavaScript and keep it all inside of the browser, you still need something to push the data out to the host so it can write it to disk or whatever.

if you're building a JavaScript application that's all or mostly JavaScript I question why you'd be using FoxPro in the first place. If it's self contained in the browser, then it's probably better served to just be a Web application altogether with no need for FoxPro (or FoxPro only as a service backend). But that's a completely different use case than building a hybrid desktop Web application, where the browser is integrated **as part of the desktop application** for something like Help Builder, or >Markdown Monster or even WebSurge which all use this hybrid application model.


I'm working through upgrading Markdown Monster from the Web Browser control to the new Web View at the moment and there are lot more quirks with the WebView than with the Web Browser control. Performance is considerably worse - it's noticable in the editor. So while the standalone browsers might be much faster and more efficient in an integration in Windows that might all get lost due to the integration interfaces and event forwarding across process boundaries.

The Web Browser control is actually the easiest and most portable way to get Web content into a form. It's dated but it works with original HTML5 which is quite capable. If you control your own content it's easy to build content that works well with it and looks great. But it is obviously discontinued and stuck at IE11 max rendering level which doesn't get the latest HTML/JS feature. Things like ES6+ and CSS3.5 and various new DOM APIs are not available in the WebBrowser control and never will be. But if you control content it's quite workable to build content that works with IE11 with reasonably recent Web componentary.

The WB control is also stable and faster than any of the Chromium controls I've worked with (both in Fox and .NET) because it's natively integrated where the Chromium controls require internally running services for interprocess communication. It depends on what you need to do - if you control the content you can control the HTML 5/CSS/JavaScript used and as long as one can stay away from ES6 and the latest CSS features IE does a pretty decent job of rendering content. Sure it would be nice to use Chromium and ditch ES5 at minimum, but for integration there's no easy solution to that in FoxPro. To see what I mean you can check out Cristof's CEF session at the previous Virtual FoxFest - it looks terribly finiky to get going. I've used CEF in .NET and even there it was difficult to keep it running reliably. I can only imagine what the extra layer of ActiveX does to stability.