Yes, the built app also didn’t work. I tried with Adobe Reader set as default pdf viewer and without.
Clicking on the OLEContainer did not do anything. It was still stuck on that “initializing” screen. Resizing did not help, nor did adding Me.Refresh(True). In the built app, no “initializing” is seen, just a grey box.
It seems, for me at least, that neither native HTMLViewer with Adobe Reader nor OLEContainer with Adobe Reader is the a workaround for whatever the issue is. I would also be interested to see how to use PDF.js. Thanks!
This seems to be an issue with Adobe itself. Was trying to find a solution for the “stuck at initializing” which has led me to countless posts like the following
I have been using something called Sumatra pdf and here is the link for it. I download the portable version. I have been using this for Window apps for the last 10 years
@Matthew_Combatti , you tease me with an easy fix it did sound very promising but unfortunately, that didn’t help. I turned off protected mode following these instructions:
and restarted Adobe Reader, checked it is set as the default app for PDF.
Now when I try the native HTMLViewer, it does not show the initializing progress bar, just a grey screen. I’m not sure what changed, even after I turned protected mode back on, the initializing screen doesn’t appear anymore. The OLEContainer also still doesn’t work.
In the first post that you referenced, someone commented “1. Set EXE compile to x86 CPU”, which got me thinking. Adobe Reader seems to be 32-bit as it installs into the x86 folder
C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe
My system is 64-bit operating system, ARM-based processor. Is this a potential cause of incompatibility? I can open Adobe Reader and it seems to work ok…
Have you dome anything about this? I was hoping to work around teh need to be able to display a PDF with high quality and zoomable etc WITHOUT letting the user be able to save or print the file (well disabling printing I already do for PDFs fro app[s that respect teh setting), but I am not sure I can…
Buying the DynaPDF Pro plugin for that is like to swatting a fly with an atomic bomb!
I ASSUME the DynaPDF plug could be used to display high quality PDF in a canvas and be able to zoom and scroll through the document and hopefully without needing to create a file on disk as well as not permitting printing or saving. I am downloading the PDFs from a database-. (can it?)
So I could use such a control right now…
I don’t think there is any solution I can get to do that in Xojo short of the DynaPDF Pro plugin. (does anyone know of any such?)
Every way i can find the user can at least make a copy of the PDF even if it protected.
Here is an update from further testing. DesktopHTMLViewer DOES load PDFs properly on Windows (Xojo2021r3.1)! It seems that it is only the deprecated HTMLViewer that does not. So there is some good news.
I created a new project using Xojo2021r3.1, added a DesktopHTMLViewer and tested it on Windows and it worked. My understanding is that DesktopHTMLViewer is always Webkit, there is no option to choose the renderer.
In retrospect, it was silly of me to assume that HTMLViewer and DesktopHTMLViewer would act the same, I was foolishly reassured by the API 2 documentation saying that the old and new controls would behave the same and could be mixed and matched.
At this time, I am unable to transition my entire project to the new controls as there is a bug that prevents control sets of DesktopUIControl from being dynamically added at runtime, but it is good to know that once a few more bugs are ironed out, I can hopefully transition and things will work
Ok, some bad news now. HTMLViewers from existing projects can’t be changed into working DesktopHTMLViewers (in terms of PDF viewing).
I’ve tried changing the super of my subclassed HTMLViewer (called AutoFocusHTMLViewer) to DesktopHTMLViewer, but the instances still don’t work. In the IDE they also still display the option for choosing the renderer, so they appear to not have changed into the new DesktopHTMLViewer type.
I then tried deleting an existing AutoFocusHTMLViewer and adding a new instance from the Library. However, the new instance still had the option of renderer, so clearly its super is still not a DesktopHTMLViewer
I then tried creating a new subclass of DesktopHTMLViewer, called ProgramHTMLViewer. DesktopHTMLViewer was not even listed as an option in the DesktopUIControl category when choosing a super (perhaps there is a problem caused by trying to use both HTMLViewer and DesktopHTMLViewer in the same project?). I had to manually type it in, which was accepted. However, instances of ProgramHTMLViewer still did not display PDFs.
My conclusion is that DesktopHTMLViewers will display PDFs if created in a new Xojo 2021R3.2 project, but will not work when converting an old project
I downloaded it the example and have been playing with it and I’m finding it a bit rough around the edges and little slow. More of a proof of concept rather than a finished control.
Scrolling pages is OK but within a page is not great… The zoom functionality(besides being only one level) does not always posit teh picture correctly after resizing the the window.
Outside of the speed perhaps, the rest is just optimizing the Xojo part of the code to handle those things better after the picture is rendered in the canvas… While the thumbnails are nice I suspect that are part of the reason for the slowness (even though they are rendered in a thread).
By just resizing the window before showing it show the PDF to the proportions of the PDF based on the available screen real estate makes it looks better…
Resizing the window to to fit as much of of the PDF on screen as makes sense after a zoom might help too. (as would a horizontal scrollbar, and vertical one for within page… I think the listbox with the thumbnails just scrolls pages - but I need to look a that code a bit )
A full control is planned and will need to have lots of bitmap caching to speed it up.
It may work well, if you just render full pages and show them with a button to switch to next page.
After much hair pulling, I have finally isolated the cause! The issue actually affects both HTMLViewer and DesktopHTMLViewer and is caused by the presence of a CancelLoad event handler! Even if the handler is blank or specifically returns false, it prevents PDFs from loading on Windows.
I have opened a new feedback report 67420. It is probably the same bug that was reported in 65219 in July 2021 where a CancelLoad handler prevents cookies from working on Windows.
So if you don’t use the CancelLoad event, this issue won’t affect you.
That’ll teach me for not asking for a demo project, so many time its not reproducible because people do things that they don’t mention. I’m glad you finally got to the bottom of it.
It’s interesting that it was also happening when you tried the cef demo projects.
guilty! I made too many assumptions without rigorously and systematically testing them and I will try to avoid this in future. I really do appreciate you taking the time to help me.
To be fair to myself, who would’ve thought that a CancelLoad event would affect PDF loading?!
I’ve added some points because this one tripped me up a few months back. I discovered the CancelLoad cause, but had no idea it was because of cookies. Thanks for your research!
it did sound very promising but unfortunately, that didn’t help. I turned off protected mode following these instructions:
The issue actually affects both HTMLViewer and DesktopHTMLViewer and is caused by the presence of a CancelLoad event handler! Even if the handler is blank or specifically returns false, it prevents PDFs from loading on Windows.
guilty! I made too many assumptions without rigorously and systematically testing them and I will try to avoid this in future. I really do appreciate you taking the time to help me.