Mimicking the old HTMLViewer constructor behavior? (passing a HTML document as string instead of loading an URL)

Hi, I’ve recently purchased Xojo 2021r3.1 and I read in the accompanying documentation that HTMLViewer has been deprecated in Xojo 2021r3.1 in favor of DesktopHTMLViewer. It’s a shame because what I wanted to use is HTMLViewer since it has a constructor that easily allows for passing a string that represents the whole HTML document.

Anyway, in the control library, I don’t see the DesktopHTMLViewer control so for now I use what I found which is HTMLViewer. Weirdly enough, even tough it’s named HTMLViewer, it behaves exactly like a DesktopHTMLViewer meaning that the constructor takes only 1 parameter, which is the URL to load.

I’m trying to inject a whole HTML document into a blank HTMLViewer (or DesktopHTMLViewer or whatever) control and this was doable with HTMLViewer control for Xojo releases prior to exactly the one that I purchased recently and it no longer seems to be doable with the new control (DesktopHTMLViewer). What would be the simplest way of mimicking the old HTMLViewer constructor behavior? (passing a HTML document as string instead of loading an URL)

…inb4 DesktopHTMLViewer.ExecuteJavaScript which is quite janky. Hope there is a better alternative.


Did you try:

Var f As FolderItem = FolderItem.TemporaryFile
HTMLViewer1.LoadPage(your_string_here, f)

as mentioned here:

The docs could use more documentation on that method! It’s not exactly intuitive!

What is the point of f?

Is define a location where a temporary file is created for the data from the string because the API’s they are using under teh hood can only load files?

If so it seems a waste of resources (though I don’t don’t if HTMLViewer does that under the hood).

If not, is it just in case the HTML data references another file? That would imply if there are no such references one should be able to pass NIL instead of wastefully needing to instantiate a folder item object… If that here the case f should be an optional parameter.

In any case IMO Xojo Inc has some splanin’ too do!

(yes I watched I Love Lucy!:wink: )


At first, I thought this was impossible, due to the IDE incorrectly showing the syntax as depicted in the following screenshot:


But yes, once you force the DesktopHTMLViewer syntax, it seems to work. Although, this raises another question:

Is there a way to NOT create a reference temp file every time I want to directly render arbitrary HTML into the HTMLViewer control? What if I were to refresh this every couple seconds? Wouldn’t this use lots of resources and grind on the drive for nothing? Ideally, I would like to not save anything to the hard drive and render the HTML document from a variable (RAM).

The IDE only shows one option from the 2 available:

Have you tried:

Var f As FolderItem
HTMLViewer1.LoadPage(your_string_here, f)

f is nil here.

Ah, yes, I misread that f had to remain NIL. It makes more sense in regards to my question now. In this case, do you know if it still creates temporary files every time it loads?

In the documentation example they assign a folder to ‘f’ so f is not nil there.
If you change the sample code and not assign a folder then ‘f’ is nil.
I guess Xojo doesn’t create a temporary file to a nil folderitem.


HTMLViewer1.LoadPage(your_string_here, nil)

In my code, it looks like that for Windows I always write the html file to disk and then use LoadPage (f). For Mac/Lin, I use the other formulation, with f sometimes being Nil. For Mac, if your html is trying to load local images (so, from your own disk), then you need f to point at a folder containing the images, and then grant the Viewer permission to load images from it.

Some of this circumlocution may no longer be necessary, but I can’t be bothered to test, at this point…

OK this actually works AlbertoD, so it’s even better than declaring f. I think we can close this thread, since it probably solves that mystery around HTMLViewer in 2021r3.1


TimStreater, in my case the HTML is all included, no other resources need to load from the loaded HTML page in the HTMLViewer, but your paragraph might come handy to somebody else coming here in the future. Thanks