HTMLViewer renders a website incorrectly

Hello,

I’m using the HTMLViewer control to show an external website. However, it renders incorrectly (looks like some css are being ignored): text fields are too large and a white background is missing, for instance. I don’t own the website.

This is when the renderer is native. If I set it to WebKit, the page stays blank.

May I post the link of that website? (it’s in French)
What else may I try?

If it is under Windows, you may want to modify the registry to benefit from the latest rendition engine. By default it uses the IE 7 rendition engine which may not support recent CSS.

See
http://blog.xojo.com/2016/01/04/use-newer-version-of-internet-explorer-with-webbrowser-and-htmlviewer/

Otherwise you can also try to set the control’s renderer to Webkit.

Yes, it’s under Windows, sorry to have forgotten to mention it (I thought of it only before I wrote the message…).
Thanks a lot, Michel. This is exactly what I needed. Now, my app adds itself to the registry and relaunches itself (the change needs to be done before the app launches).

[quote=296401:@Michel Bujardet]If it is under Windows, you may want to modify the registry to benefit from the latest rendition engine. By default it uses the IE 7 rendition engine which may not support recent CSS.

See
http://blog.xojo.com/2016/01/04/use-newer-version-of-internet-explorer-with-webbrowser-and-htmlviewer/

Otherwise you can also try to set the control’s renderer to Webkit.[/quote]

Michael, your post is a couple years old now. Is that method still recommended?
I have a bizarre situation where I ran that (registry editing) from my application and set a flag to only do it one time. The html looked great. On subsequent runs with new builds, that registry entry is not set again (and it should not have to be again), but the old renderer is being used. I can confirm that the registry entry remains, and that the EXE has not been renamed.

I’m a Mac guy, so I really don’t get this, except to say that it’s strange…

Any hints?

Or you can use WebKit and you wont have to mess with users registry entries (which can be restricted in some set ups and may not always work).

Jason, the reason I deviated is because I read that it won’t support the system proxy server. Can you confirm that?

As for system proxy configuration, I have no idea if WebKit uses the system wide settings or not (which are configured differently depending on what version of Windows they’re using).

in a separate thread, Christian Schmitz confirmed that this was the case.

Chris - Okay, that’s good to know.

In all pragmatism, I would tend to set the registry every time the app is launched. Another app may change the settings.

[quote=387861:@Chris Halford]Michael, your post is a couple years old now. Is that method still recommended?
I have a bizarre situation where I ran that (registry editing) from my application and set a flag to only do it one time. The html looked great. On subsequent runs with new builds, that registry entry is not set again (and it should not have to be again), but the old renderer is being used. I can confirm that the registry entry remains, and that the EXE has not been renamed.
Any hints?[/quote]

I have apps that rely on this technique, and I’ve never seen it fail like that, with the exception being if it’s on some sort of managed PC where the IT department has (unreasonably) locked it down.

I set the registry key each time - maybe that’s required?

I do it in App.Open to make sure it’s in effect before any windows open.

App.Open
  SetIE11BrowserEngine()

Sub SetIE11BrowserEngine()
  #if TargetWin32
    Dim reg As New RegistryItem("HKEY_CURRENT_USER\\SOFTWARE\\Microsoft")
    reg = reg.AddFolder("Internet Explorer")
    reg = reg.AddFolder("Main")
    reg = reg.AddFolder("FeatureControl")
    reg = reg.AddFolder("FEATURE_BROWSER_EMULATION")
    reg.Value(App.ExecutableFile.Name) = &h2af9 ' IE 11 renderer
  #endif
  End Sub

Michael,

It’s amazing how AWFUL the native browser looks compared to when I specify WebKit.
The developer of the server noted that it was rendering like a really old version of IE.
So I implemented your code exactly and nothing has changed. I must be missing something.

Right away, I see you search for TargetWIn32, and I changed that to TargetWIndows (it’s a 64 bit system).

Next, I’m admittedly the least knowledgable person on the planet when it comes to Windows. I’ve been a Mac guy forever.
Are there any conditions that would block the registry from being updated or read?

Is IE even on the newer Widows OS? I thought they changed it.
Could the 64bit system mess something up?

Anything else you can think of?

Chris,

  • Even in 64 bit builds, the framework is called “Win32”, so at the moment TargetWin32 and TargetWindows have the same meaning.
  • While I know the registry hack works in 32 bit builds, I’m not sure about 64 bit builds, so I suppose it could be broken? Have you tried it with a 32 bit build? 64 bit windows OS is perfectly happy running 32 bit apps.
  • Windows 10 has the full IE11 application and engine installed (and I suspect will for a long time, for backwards compatibility). What version of Xojo and Windows are you using?

Michael,

My final solution was to use a 32bit Windows build. My customer is a bit frustrated with it, but c’est la vie.
I’m using the an up to date Windows 10 and the most recent Xojo.

Ok, it turns out our old sample code does not work in 64 bit builds. Here’s newer code which does work in 64 bits.

Public Sub SetIE11BrowserEngine()
  #if TargetWindows
    // this is an updated version of the function which handles both 64 and 32 bit builds
    // for Xojo 2018 R1 or later
    #if Target64Bit
      Dim reg As New RegistryItem("HKEY_CURRENT_USER\\SOFTWARE\\wow6432node\\Microsoft")
    #else
      Dim reg As New RegistryItem("HKEY_CURRENT_USER\\SOFTWARE\\Microsoft")
    #endif
    reg = reg.AddFolder("Internet Explorer")
    reg = reg.AddFolder("Main")
    reg = reg.AddFolder("FeatureControl")
    reg = reg.AddFolder("FEATURE_BROWSER_EMULATION")
    
    ' documentation :  https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/general-info/ee330730(v=vs.85)
    reg.Value(App.ExecutableFile.Name) = 11000 
  #endif
End Sub

I’ve emailed @Paul Lefebvre to request the blog post get updated as well.

AWESOME!

I’ve updated both the original blog post and doc page:

Thanks, Paul!
I’ve started a side-discussion about “why is this needed” https://forum.xojo.com/47881-64-bit-apps-and-the-registry-wow6432node

Ok, it looks like I was wrong, and Julian identified the correct code here: https://forum.xojo.com/conversation/post/388637

Here’s the newer version of the code which appears to work

#if TargetWindows
  // this is an updated version of the function which handles both 64 and 32 bit builds
  // for Xojo 2018 R1 or later
  Dim reg As New RegistryItem("HKEY_CURRENT_USER\\SOFTWARE\\Microsoft")
  reg = reg.AddFolder("Internet Explorer")
  reg = reg.AddFolder("Main")
  reg = reg.AddFolder("FeatureControl")
  reg = reg.AddFolder("FEATURE_BROWSER_EMULATION")
  ' documentation :  https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/general-info/ee330730(v=vs.85)
  reg.Value(App.ExecutableFile.Name) = CType(11000 , Int32)
#endif

Testing this is tricky, because if you run the 64 bit app immediately after the 32 bit app, and the registry key set by the 32 app is still there, the 64 bit app will appear to work. Use RegEdit to clean out the registry keys between tests.

@Paul Lefebvre - we’ll need the documentation updated again as soon as we confirm that Julian’s code is correct.