Hello Dominique,

We use an OCX widget with the Shell.Explorer. You can simply "navigate" to the PDF document to view and print.

Alternatively you can also use the HTML-widget to view the PDF document using a small piece of HTML code. 

html_body:blockdata @










@

Use $replace to replace the file tag in the HTML code with the actual location.

Hope this helps.

With kind regards,

John

Hi Dominque

What about a OCX-container?
If you do have adobe installed, there should be an OCX for this purpose

Ingo

reading your answers, I realized I forgot to give more details

I need to store the content of the pdf  because it is linked to an invoice

So when I print the invoice, I need to print this pdf after the invoice print, knowing that this printing can be done from anywhere and when you display the invoice on the screen, I don't have anymore the pdf on disk, but need to load it from the database

We store our PDF documents in the database too. When the user wants to view the document, we save it to disk in the Windows temporary files folder. Show the PDF document and when the user leaves the form we remove the PDF document from disk,

With kind regards,

John

Is there a way to display it without having to create file on the disk

how do you store in the DB :  which kind of field

is there a way to display without using ocx I don't need any "useraction"

I would like just to display the pdf like an image and print it like an image too

So, to store in the database, use a "raw data" field (sr*) in the model. CHeck out whichever database you use for the mapped field type, and how best to store that kind of data (in SQL server for example, there is the option of filestream)

Store in the database by using fileload/raw (lfileload/raw), to populate this field and then store the entity. 

We don't use the uniface reports to print, but I think they'll have the same issues that crystal reports does, in that the PDF won't print, or will only print the first page. 

If you look for ghostscript online, you'll find an executable that will allow you to convert the PDF into a series of images (tiff, jpeg, you choose), which you can then re-load into the report as a dummy entity using fileload/image, which will allow you to include these 'pages' alongside your invoice. 

So your report code save the file from the database to a temporary location, runs the ghostscript executable to chop it up into images for each page, loads those images back into dummy fields in a dummy entity (one occ per page), runs the print, and then deletes the temporary files.... simple, no? 

I can (maybe) give some hints what the various loops and command lines look like if you want. 

Oh, and while you're at it, you could find my wish in the wishlist that Uniface could handle pdfs as a native 'image' type, and handle display and printing of those, and give it a vote. 🙂 

html_body:blockdata @










@

You can also load the Pdf into memory from file or from the database and use embedded data rather than the file location, (I seem to recall it needs encoding to base64 or something). 

The pdf view provided by cefrender lacks some useful functionality (rotate being the main one I seem to recall). 

We have had to go with paid software which displays the pdf in a web page using the local IIS. This has the advantage that it will display other documents (word, excel, cad files etc) as well, to overcome these limitations. 

Also, OCX containers don't print, do they? I don't use uniface for printing, so I'm behind the times on what its exact capabilities are. 

Adobe stopped providing OCX containers with Adobe XI as far as we can tell, Adobe DC has been live three years now, and only speaks .NET as far as we can tell. 

Hi Dominque,

I did a quick test with the HTML widget (using the latest Uniface 10.3 patch, 10.3.02.050) and this seems to work:

operation exec
variables
  raw rPdf
endvariables
; Your pre-edit code here...
fileload/raw "some.pdf", rPdf
HTML.ENTITY = $concat($html1, $encode("BASE64", rPdf), $html2)
; Shows the form component and allow data entry
edit
return 0

html1:blockdata ~
~

end

The HTML widget (or better said CEF) has an embedded PDF viewer.

The above sample code should also work if you use a RAW field (data type: RAW, Interface SR*) instead of a RAW variable.

During my quick experiment with this I've recognized that there seems to be a problem with larger PDF files (> 2MB). The HTML widget will not show the PDF viewer, but just a blank page. When I open the same page with the Google Chrome browser then I get the same result. I'm not sure if there's a limit for the src-element, or some other limit or bug.

I hope this helps.

Kind regards,
Daniel

html_body:blockdata @










@

When I check the latest Uniface 10.3 patch (10.3.02.050) then you can actually rotate a PDF document in the viewer.

html_body:blockdata @










@

Ah, we're only just migrating to uniface 10 for production, must have been following the cef version update. We've been using other software to display pdfs (and other documents) for a couple of years now.