Include AcroPDF in executable

[rolfk]

---

@aputman wrote:

---

@JeroenBK wrote:

For now I will check for the plugin to be available, if so the option to preview becomes active, otherwise it will be skipped.

---

I'm not so sure it will be that simple.  Using ActiveX requires property and invoke nodes to call the methods in the DLL.  If the DLL is not installed, you'll end up with broken property nodes and missing DLL errors that will render the application unusable.  If you add this functionality to your code, you should make sure that Acrobat is installed thru the use of a custom installer

---

I've done this in the past with other ActiveX components. It required me to write a top level VI Interface (since it was pretty simple I decided to create one Intelligent Functional VI with several methods for each plugin). Then a wrapper was build that would call those VIs dynamically through VI server. On startup each plugin was attempted to be loaded and if the returned VI refnum indicated a broken VI, this plugin was disabled and not possible to select as an option in the application. That worked!

But you can indeed not have a static linked VI in your hierarchy that may contain ActiveX or .Net nodes for something that is not installed.

[JeroenBK]

Hello,

What I do for now is use the PDF Toolkit to create a pdf and save that pdf in a temporarily location. Then load the VI with the ActiveX in it (without opening the frontpanel), if loading the AcroPDF gives an error, the VI is closed (error is reset) and the pdf is saved in the definitive location (without removing any pages). That seems to work fine.

The only thing I don't understand is that this program is used within my company and everybody has Adobe Reader installed (via ICT managed system, so it should be the same version as well). Why some users get an error due to the missing ActiveX is not clear to me. Maybe it has something to do with different versions, or if they have Adobe Acrobat (the editor) they don't have the (same) ActiveX???

Best regards,

Jeroen

[BowenM]

One option would be to generate images of each page after you make the PDF.  I know the iTextSharp DLL can do this.

[JeroenBK]

Hello,

I found the location of the AcroPDF.dll so now I would like to see if it is possible to check on the presence of the file and if not prevent the VI from loading in my executable. Checking on the file is no problem but how can I prevent the VI from loading?

Best regards,

Jeroen

[GerdW]

Hi Jeroen,

you can use VIServer functions (methods) to call any VI anytime you want/need: the VI will get loaded into memory only when you need it…

[JeroenBK]

Hello Gerd,

Do you happen to have an example on how to do such call with an executable?

Regards,

Jeroen

[GerdW]

Hi Jeroen,

how to do such call with an executable?

In an executable you use the very same functions as in the development environment: OpenVIReference and a VIServer method to start the VI:

(There should be an example VI in the example finder explaining VIServer methods…)

[Hooovahh]

I don't have an example of it now, but I have used that ActiveX control in the past to embed a PDF in my front panel.  I included the Adobe installer in my installer, and ran a silent install switch when my application was installed, which would add and register that ActiveX control so my application could use it.  This did occasionally have issues and I blame it on Adobe's constant updating of a program that doesn't need it, if they just lock down some of the security of it.

[JeroenBK]

Dear all, 

Thanks for the input and ideas. For now I've solved it a bit different. I've created a "download-bar" just like Chrome has. As soon as a file is saved it shows in this bar. On the fly editting as I wanted is no longer possible, it was a nice-to-have feature to begin with. I agree with Hooovahh that constantly updating the reader doesn't do any good.