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.
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.
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? example.com isn’t helping
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).
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.
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.
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.
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
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
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.
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.