In Xojo 2021r2.1, on Windows, in a webkit renderer HTMLViewer, I could use:
and the pdf would be displayed in the HTMLViewer.
In Xojo 2021r3.1, on Windows, in a webkit renderer HTMLViewer, the same line of code will not properly load the pdf.
I can see from the DocumentBegin event that initially the correct URL is being loaded, however, immediately a new DocumentBegin is raised where the URL is
and the HTMLViewer displays nothing.
I note in the Xojo2021r3.0 release notes that
64854 Framework » Windows Updated Windows WebKit HTMLViewer to CEF 90.6.7+g19ba721+chromium-90.0.4430.212.
I assume that this updated webkit version is responsible for the broken functionality. Is this considered a bug that I should report or is this expected behaviour? Would anyone know of a workaround? Native renderer does not work as it downloads the pdf rather than displaying it.
Thanks for your help.
Thank you for this posting that …
I am writing code that vitally depends on that ability… although I am coding in 2019r1.1 so would not see this at this stage, I will need to deploy in a newer version as I need the updated Postgres plugin…
Now I know not to compile with 2021R3…
I literally posted an example yesterday demonstrating using PDFs in HTMLVIEWER. It’s your version of Xojo or your code that’s causing the issue. It works fine here and for the new developer we showed how to implement the feat yesterday.
**Just downloaded the example I created yesterday and tried on my personal laptop, loads just fine. Check your code or try another version of Xojo.
You’ll be fine, just tested 2019r1.1 and works there too
You could try WebView2ControlMBS control in MBS Xojo Plugins instead.
Yes the issue is definitely related to the version of Xojo, it occurs in 2021r3.1 but not 2021r2.1. I don’t know about 2021r3.0 - I thought I was being smart and skipped that version, waiting for the inevitable bugs to be fixed first…
Currently as a workaround I have told the users of my app to select the option that will open PDFs externally instead (using GoToURL).
I think I will open a case in Feedback. Surely this is not an intentional change.
I might recommend you make a case for a PDFViewer control, because honestly HTMLViewer is not a PDFViewer. It just so happens to work on some systems.
I have opened up a Feedback case: 67294
Also, Tim I was going to follow your suggestion and open up a feature request for a PDFViewer control, but found that there is still an open case from 2009! 10405 . I have added it to my Top Cases, but it is still ranked 558th
Do you what is required to make sure i works on Mac and Windows?
Geoff made the feature request… I guess even he has to wait a long time!
To be quite frank, it’s HTMLViewer – not PDFViewer. It just so happens to work on some systems. It is not the fault of Xojo when it does not.
The issue of it not working on all systems comes up too frequently and is constantly tripping up new users because of all the bad forum advice of “use HTMLViewer to display PDFs”
I make my recommendation so that future users don’t get tripped up by this issue.
I agree Xojo should have a PDF viewer built in these days give the ubiquity of PDFs, and now that they support of creating them even more so (though mine start life as Word Docs)…
Ideally I would want to be be able ensure end users can only display and not save or print the PDFs… But I’m not going to pay $1000 for an MBS DynaPDF Pro license for that! And displaying PDFs is all I need that I don’t have.
In my quick tests using the HTML viewer, it gave more more control than launching a PDF to be displayed in a browser.
I’m not saying it’s Xojo’s fault that the HTMLViewer does not work for displaying PDFs on all machines…
All I’m asking is there way to ensure it will work, like on Windows requiring Acrobat reader or some such also be installed. The app I am writing is for in-house use so can require free things like that to also be installed.
It works for me here in both versions. Have you checked that extensions/plugins you have installed in chrome?
A quick google of “chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/index.html” refers to an extension called pdffiller, maybe this is either the issue or its not working with the new version. Perhaps add that to the ticket so they know where to start looking?
Thanks for your input. I had only googled “chrome-extension” because I thought the rest was just gobbledegook! and nothing relevant had come up.
Hmmm… I don’t have Google Chrome installed on my computer, but I guess the webkit browser is trying to use it? Let me install Chrome and see if that makes a difference…
Thanks, I’ll add a note to my ticket.
You can use “add” and select activeX on Windows, then choose one of the PDF viewer controls. Windows comes with one built-in, so unless you require Adobe or the likes, you can use native activeX controls on Windows. Mac and Linux systems don’t get this added benefit of having access to system native and installed/added controls.
**Adobe, for example, would require the user also have Adobe installed, or a redistributable of the ocx control.
Hmmm, I stand corrected, it looks like an internal part of webkit, the google hit I found earlier was just a pdf file with the same reference, of which there are plenty on the interwebs.
Well, I just installed Google Chrome and set it as the default app for pdfs, but unfortunately that has not made any difference.
@anon20074439, would you have any other suggestions as to why it works for you but not for me? I have tested on Windows 10 and 11 and it doesn’t work on either for me.
@Matthew_Combatti, I haven’t used activeX controls before. I’m just looking at the documentation for OLEContainers now. What programID would I use to access the Windows built-in PDF viewer?
If you load it off local disk, does it work?