HTMLViewer on Windows not working for some users

I have recurring reports from users that my tool Arbed acts up on Windows when it involves using HTMLViewer, e.g. when using menu command Help → Purchase… or when opening a Xojo project and then choosing the menu cmd Export → to HTML…

People then either get exceptions (internal error) or other odd effects like this:

Oh dammit, why can’t this forum host pictures?!

Anyway. it always works fine on my Win installations.

Now, I came to suspect that it’s because I have Webkit installed on my Windows system, because I once installed Safari or Apple’s Bootcamp support on it.

However, since I’ve never changed the HTMLViewer.Renderer property (i.e. it’s set to 0 - Native), I don’t see why this should be a factor in it.

According to the docs (, it should simply use the IE renderer, right?

Arbed is currently built with Xojo 2014r1.1 as I have no later Windows built licenses. But I also believe that older versions of Arbed, built with older Xojo versions, didn’t have this issue, as I should have gotten more reports back then but only start getting them now.

Any ideas what’s going on?

I have no issues with HTML Viewer on Windows.
If you haven’t changed the renderer it will use their installed IE. I force HTML Edit to use WebKit because, well, IE… The downside to forcing WebKit is that WebKit gets bundled in with the resources on Windows, and Linux users must install it themselves. It’s not a terrible downside, but it’s worth noting.

Can you be a little more specific with the errors? isn’t helping :wink:

Don’t mind me testing tricking the forum into hosting images…
Edit: Hah! It worked. Probably not a good idea to abuse that though so removing it.

The image I wanted to show is a rendering showing a short error message (I suspect), in Chinese (I suspect), but then the user is also from that suspected country. Anyway, the point is that that user didn’t get an exception but instead got a rendered page, but not with the contents I wanted to render into it (which would have been readable source code).
(And no, it’s probably not blocked by a great firewall because the text came either from a local html file or got generated by Arbed, i.e. the HTML source code output).

Here are the pics:

The first appears inside Arbed - that’s when using “Export -> to HTML” in Arbed.

For the second I do not understand where it comes from, even. The path in it suggests it’s a file inside my ArbedWin’s folder (containing Arbed.exe), but that file name is not something that comes with Arbed. No idea what I’m seeing there.

The first screenshot looks like an IE notice page, I cannot however tell you what it says.
The text that it says would probably be somewhat helpful.

I did a quick google on navcancl.htm because it sounds like this is a problem with their system.
This document suggests re-installing IE, and removing any and all toolbars installed.

Are your other reports of similar nature? This seems specific to this user.

Edit: Unwarranted guess - they have a malicious toolbar installed.

when you load html to the htmlviewer, Xojo actually writes a temp file and load that.
Now I could imaging the temp URL for that temp file has special characters and fails to load.

I do have HTMLViewer.IELoadHTMLMBS in my plugin which works without temp file.

Or you create your own temp file with ASCII characters in path.

Oh hey, upon reading that I noticed the D: path had invalid chars. That could be the kicker.
I had trouble with build automation on Windows once because Xojo was giving me a similarly cryptic path.

Tim, thanks for looking into that. I’ll suggest that to the user.

So, maybe these are separate issues indeed. Will see what the other user getting the exceptions says.

Christian, indeed, I use this code currently:

view.LoadPage htmlText, App.ExecutableFile

Meaning that Arbed provides a String, which then has to be written to a file as you say, which would explain also the file that the chinese user sees.

Okay, I’ll dig into those possibilities. Maybe the file can’t be written for the other user and hence the exception.

Try changing App.ExecutableFile to GetTemporaryFolderItem
My issue with build automation on Windows came from trying to get the build path and I got a bad path from Xojo.

You’re welcome! I hop into any thread with HTMLViewer as I have an interest in making sure it continues to work :slight_smile:

Tim, you sure GetTemporaryFolderItem works? Shouldn’t it be GetTemporaryFolderItem.Parent (or SpecialFolders.Temporary), in order to get the actual folder? But I assume you had success using GetTemporaryFolderItem?

The documentation example uses GetTemporaryFolderItem. GTFI creates a file inside SpecialFolder.Temporary to use. It basically saves you the step of creating a temporary file to use. The RelativeTo FolderItem needs to be a file not a directory. I ran into that issue in the past.

Thanks for the clarification, Tim. When I used Webkit on iOS or OSX, I believe I had to specify a folder, hence my confusion - but I may be even wrong there, too :slight_smile:

I’ve now built a new test version with the change ( and will ask my users to try it. Will report back then.


DuckDuckGo is your friend :

Apparently, the page that failed is :


Looks like your user has created a folder D:\\XOJO*a****\\ where “a***” is probably the result of Chinese characters going through the CP-1252 Dos encoding, resulting in a series of stars, notorious forbidden character.

I would advise him to use another name for his local folder, such as D:\XOJO1234 or anything that does not use ideographs, and the error will probably go away.

Michel, good find. Though, if the path were the problem, then nothing in Arbed should work, as the entire app is inside that folder. With Tim’s proposed change, this issue will solve itself, probably. However, I’ll keep your thought in mind, should more issues arise for that user.

If you aren’t setting FEATURE_BROWSER_EMULATION then your WebView will be using an old version of the IE engine, which can also cause issues. See

Michael, but that doesn’t apply to my case because I’m not using Webkit on Windows. Agreed?

No no no. Has nothing to do with Webkit. Everything to do with native browser engine.

Other way around. The registry hack is to select the version of IE you want to render the page.
I believe we pinpointed the issue to the path problem though, so I don’t think you need that.

Edit: Michel beat me to it!

My best bet is that 67054.html simply does not exist.