MSComDlg.ICommonDialog ShowPrinter method doesn't work in LV v8.20

[lgk]

I am converting a released application from LabVIEW v6.1 to v8.20 due to having to upgrade the data acquisition board for the application from an E Series board to a M Series board.

In the original application, I used an example VI from Nat'l. Inst. (Printer Demo v6.1.llb) to display a print dialog.

In that example VI, the ShowPrinter method is invoked to display the print dialog. This all worked fine in v6.1

In version 8.20, the VI does not show an error, and so is executable, but the print dialog is not displayed - the application just proceeds directly to printing the document in question without allowing the user to select printer, etc.

What happened? Something has changed, but I can't figure out what. I have recreated the Invoke node and reselected the ShowPrinter method, but no success.

I have attached Printer Demo v6.1.llb (upgraded to v8.20).

[DuffmanSays]

lgk,

When I run the example that you have attached, the print dialog pops up on my screen. I was wondering if the example is still working properly on your machine in LabVIEW 6.1. Also, have you tried the example on another machine running LabVIEW 8.2?

I ask because the way this VI is working is through ActiveX calls. We can determine if this issue may be ActiveX related if the VI no longer works in LabVIEW 6.1. Also, have you have tried printing a document from Microsoft Word directly? I would expect the dialog to show up as usual; I assume that Word would make use of the same ActiveX call. Please give these a try and post back if it is still unsuccessful! Thanks,

Mike D.
National Instruments
Applications Engineer

[lgk]

Mike:

Thank you for the reply.

Since my original posting, I deleted the original (v6.1) refnum control that feeds the Automation Open VI and recreated it (in v8.20). This has made the problem go away - on one computer, but not on another.

Right now I have two computers going. My original development computer (Win2000) had LV v6.1, CVI v5.5, ComponentWorks v1.0, along with Visual Studio v6 (VB and VC++). The printer dialog worked under LV v6.1, but when I got v8.20, I removed v6.1 and installed LV v8.20. Under v8.20 the printer dialog didn't work (as previously described), but I have since gotten it to work (see paragraph above). The second computer (WinXP) has only LV v8.20 installed, it was put into service because the original computer met only the minimum hardware requirements for LV v8.20 and I thought some of the problems I was having might be resolved by more memory, etc. Even though I have tried the same trick on the second computer that worked on the original computer, the printer dialog continues not to work on the second computer.

Yes, the printer dialog works (on both computers) from Office applications (Word, Excel).

When the Automation Open VI fails, it says that it is not licensed to use the ActiveX class. How does one go about getting licensed to use an ActiveX class? I guess I 'm licensed on the Win2000 computer and not licensed on the WinXP computer, but then it told me the same thing on the Win2000 computer until I deleted the refnum control and recreated it.

I'm not getting anywhere on this.

[DuffmanSays]

I believe this issue is related to the Microsoft tools that are installed on your PC2. In order to work with your LabVIEW development environment, you need a development license for the ActiveX control. This is most likely installed with Visual Studio, which explains why PC1 was able to use this ActiveX control. I'd say your best bet is to install the Visual Studio. Take a look at the following article concerning ActiveX and licensing.

One other resource that might be useful to look at is a knowledgebase that discusses a patch for certain ActiveX controls. This knowledgebase actually links to a MSDN article that would be useful to read first. If this ActiveX control is based on VB 6, then you may be able to apply this patch to resolve the error.

Good luck, and please post back if you are still not able to get this working. Thanks,

Mike D.
National Instruments
Applications Engineer