Developing software in LV2009 that uses Report Generation Toolkit to read/write from Excel templates. Program runs fine in development mode. AppBuilder crashes on *.exe build when adding NIReport.lvclass:Print Report.vi Digging down, I find a broken run arrow on the NI_Excel.lvclass:Print Report.vi as shown here: According to the Show Errors dialog, there is an unwired or bad terminal on the PrintOut invoke node; however I have not made any changes to this shipping VI (that I know of). I did try wiring all the unused inputs (empty strings to From, To, and PrToFileName; false booleans to Preview, PrintToFile, and Collate) after I ran into the error, but that had no luck either. Also tried inserting To Variant conversions for all input elements, just in case there was a problem in the implicit data to variant conversion. I have also tried a ctrl+shift+run compile of the whole application, but that doesn't seem to get it to un-break, either. Has anyone run into this problem before? It's weird that it would just break like that--I had actually compiled this particular executable before, using pretty much all the same Report Generation Toolkit VIs that I am using now. The only difference since the last build was that I replaced a Report.SaveAs function with a Report.Save function. Also of note: I have included all the Report classes in my project and build specification in order to compile the dependencies into support libraries to minimize the number of labview files included with the executable distribution. This is probably why an error with the Print Report.vi calls is crashing the AppBuilder even when I don't explicitly call that VI anywhere in my code.

EDIT: Nevermind. I fixed the problem. But in case someone else runs into the same issue, here's what I had to do: Change the Invoke Node method. Then change it back. That's all. I have no idea why it would spontaneously STB like that, but it seems that changing the method to something else and then back managed to jog its memory. It's always something....

LabVIEW

Application Build Failure on Excel.Print Report call

Solved!

I ran into your issue as well. In my case, it all started when Excel decided it was no longer licensed (something expired?), and I had to sign in again (Office 365? It wasn't clear.) and repair Excel in Programs and Features to get XLSXs to open properly from Explorer.

Any one of those things must have broken something in the ActiveX "Invoke Node", because my custom "write to Excel" block started throwing an error. I changed the invoke node method, changed it back, hooked the wires back up EXACTLY where they were before, and order is restored to the universe. Back in business.

Weird story, I know, I don't understand it myself, but that's just what happened. 1,000 internet points to you, sir.

Message 11 of 11

(530 Views)

LabVIEW

Application Build Failure on Excel.Print Report call

Re: Application Build Failure on Excel.Print Report call