Desktop HTML viewer fail with 2020 R1

Thanks for the lead. Point is, my prior version worked fine in 2019R3.x, and failed under 2020R1, so something changed in how the HTMLViewer operates, and that appears as I wrote above. I’ll think about your idea Rick, and am loath to yet again tear apart good working code in the name of progress.

Here’s another one … HTMLViewer 2019RX would open a file without a file extension, for example a temp file. R20 won’t, so more code changes.

The Release Notes for 2020r1 says:

Updated HTMLViewer on macOS to use WKWebView.

Yup. Yet it does not say what, exactly, that changed. For those using HTML quite a bit for desktop apps, we get to find out by the hard way.

WKWebView is the new Apple class and you’d almost have to read the description on Apples site as to what it changes from the old underlying class (WebView I believe)


sadly, 2020R1 isn’t ready for prime time IMHO.

Here’s another one: simple new desktop app. Add an HTMLViewer and a canvas. Set a backdrop and make the canvas visible. In R19, the zorder set by IDE is honored … set canvas to topmost and it obscures the HTMLviewer. In R20 zorder is ignored and the HTMLViewer is always topmost. Regardless of you set the two controls, HTMLviewer always obscures the canvas.

Hopefully a 2020R2 is in the works right now…

There goes my fading using transparency of a canvas…

Hopefully I’m missing something obvious.

I get this with Xojo2020r1:

I get this with Xojo2020r1:

Doesn’t matter which I choose to be at the top of the z-order…

I get this with Xojo2019r3:

Can you share a sample?

you could fade any website using javascript:

For example after document complete event:

HTMLViewer.ExecuteJavascript " = 0.5;"

0.0 = invisible page
1.0 = completely visible page.

This works better than having a canvas over it, much less cpu, mem and less work…

What are your Feedback numbers for these two problems?

Good to know! In my case, I’ve got one document that I want to fade into another. So [under R2019] I take screen shot of the prior contents, then display that over the existing viewer, update the vier to the new document, and then fade of the canvas to reveal the new new document. This way, I had (under 2019) a smooth animation where one page morphed into the other. Of course, for reasons unknown, that no longer works in R2020.

Hey Tim, I didn’t open anything up. I’ve taken the time to do it a couple times and the only thing that seems to come of it is a couple questions – aka more work on my part – to explain, make examples, etc., and then nothing seems to happen. I find the community response is more useful and efficient.

1 Like

You can do that with a javascript that loads a new

window.location.href = '';

You can also use trasitions in styles as the previous example.

The new features of the htmlviewer are worth alot since they open a full set of usages to xojo developers. You can even communicate to and from javascript to Xojo now.

Your old usage style is not recommended. Laying controls on eachoter is pretty bugged sometimes.

1 Like

One addition is you can add something to the javascript “window” object that will persist along different domains loaded in the htmlviewer.

So you should be able to set an onload event handler to fade in the other page…:wink:

21 posts were split to a new topic: HTMLViewer: Xojo + JavaScript Communication

I think I may know what causes this. Let me experiment and get back to you.

Are you saying it’s not possible at all with the IE-11 (native) renderer? I keep having to beat this stuff into submissison under Windows, I’ve been successful so far.

I split this discussion to keep it on-topic.