Current PDF Viewer component stability

Ignition
1

I’m still on Ignition 7.3.4 and working with a project that involves a lot of pdf documents.
The PDF Viewer component is being used for previewing, but the component is extremely unreliable.

There are multiple ways it can fail, at least the following:

  • The whole application can crash
  • The loading indicator leaves on spinning forewer
  • The document just won’t display

Is this still the case with the current Ignition version? If so, could you at least make it fail cleanly?
Perhaps with a configurable error message, such as “The document cannot be previewed”.

Thanks!

2

Have you tried the pdf ActiveX component?

It has some issues, but I think you can find a lot of answers to questions in this thread

viewtopic.php?f=70&t=8559

3

Greg,

thanks for the suggestion.

I believe one or more of the following issues of it will be a problem:

  • Doesn’t work on Linux (we’re targeting multi-platform)
  • Restricted to 32-bit (our server environment already needs RAM beyond 32-bit limits)
  • The Always-on-top quirk sounds harsh (but perhaps hiding it by script whenever in background
    would work…)

I’d like to hear what developers have to say about making the PDF Viewer fail gracefully instead of
varying degree of ill effects. I’d like to believe a couple of try-catch constructs would do the trick, but
perhaps that card is already used? :stuck_out_tongue:

4

I agree with your assessment of the ActiveX option.

We plan to replace the PDF viewer with something better, but we’ve yet to do a full evaluation of the commercial PDF libraries on the market.

Do this for me: launch this PDF viewer res.icesoft.org/demo/jws/icepdf.jnlp and let me know how it handles the PDFs that are causing issues with our PDF viewer.

5

I tried out a handful of files that each seemed to fail differently, and all of them showed up correctly with the ICEpdf viewer you provided.

6

Thanks for trying them out. I think we’ll incorporate that pdf library, which now has a friendly license (it didn’t last time I’d looked at it)

7

I will second you guys integrating this! Since the new Adobe update we seemed to have lost the ability to view PDFs with the ActiveX PDF Component.

8

Alright folks, try this one out:
ICEpdfViewer-module.modl (523 KB)

9

The ICEpdfViewer works a treat. Far more stable and flexible than the inbuilt and ActiveX.

1 small issue is that if using a file Explorer component to feed the PDF viewer, the viewer tries to open the folders as well when slected. This causes the Viewer to display a fault message.

“ICEpdf could not open the file at … The file maybe corrupt or not a supported file type”

Is there a way to overcome this? Maybe using an IF statement to make sure it only sees a PDF?

Cheers

Tim…

10

I’d probably put some scripting between the two to filter out anything but *.pdf files. So, instead of using bindings, you’d put a propertyChange event script on the file explorer, and see what the selected file was. if it is a file that ends with .pdf, then you push that selected file into the PDF viewer’s file property.

11

Cheers

Didn’t see that the file Browser had a property that shows a file is selected.

Swung that into a propertychange script and alls good.

Thanks again.

12

Any chance we can get an override for the “Could not open the specified file at” popup?
We are using the PDF Viewer to open and view our CAD drawings, however, the link we use actually runs a script which looks in the system to return the correct drawing number and this takes slightly longer to open the drawing.
Unfortunately it’s just long enough that it causes the “Could not open” error to popup and in less than a second later the drawing opens up behind it.
This happens with every drawing we open and can be really annoying.

Brian