Hi Rick,

I read the thread on your site - thrice. I agree that MS will probably support activeX WebBrowser Control for a few more years.

>>What will be the future of the Webrowser Control now that Microsoft has announced the demise of IE 11 this coming August?
>
>A lot of people make the mistake of confusing Internet Explorer with the Microsoft Web Browser Control/Platform which is the ActiveX based control that is widely used.

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

>Internet Explorer - the application - is a consumer of said control, but it's not the same thing.
>Internet Explorer - the application - is what's going away, not the old COM based rendering platform (Trident).

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 ?

>As I pointed out on this message board thread, there's no way in hell that Microsoft could kill the underlying COM control because it is used by a huge swath of mission critical applications, including Office (both old and new versions). It would instantly would break 30-40% of all Windows applications if they pulled this out (lots of applications use this control without knowing it through related components or dependencies). So that's not going to happen anytime soon.
>
>Further Microsoft doesn't have a good backup plan to replace that control. While there's a new WebView2 control (I've written about that in the context of .NET here and here) it's incompatible with the current control if you do anything but just displaying content. Any interaction with the new control (DOM access, handling events, etc) all works completely differently than the old WebBrowser control. Plus there's no ActiveX container - it only works with Win32 and .NET Code (unless somebody builds that which is unlikely since this one piece of dev tech Microsoft has not open sourced).
>
>Bottom line - if you use the Web Browser control and it works there's nothing to worry about - it'll continue to work. But... it is stuck in IE11 mode with basic HTML5 support, and will never be upgraded so depending on your use case it may break just because it may not be able to render certain content that uses newer CSS, HTML and JavaScript features - the latter of which is becoming a problem with some Web content. But if you're using it to build your own content to display then you can control what is used and it is quite capable still.

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 ;-)

regards
thomas