Application Build Failure on Excel.Print Report call

[TurboPhil]

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.

[TurboPhil · Accepted solution]

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....

[Sito_1]

Hey Guys,

  I know this post if kind of old but I hope maybe one of you can help me out.  I'm using an invoke node similar to what is above to print out an Excel spreadsheet to the default printer.  My issue is that when I try to print from the spreadsheet from the executable, the executable crashes.  I know it is that invoke node. The reason why I say that is because until recently I had two development computers, one running on Windows 7 LabVIEW 2010, and one running on Windows XP LabVIEW2010.  The original .exe was built with the XP machine, when I tried to make some changes with the Windows 7 machine and open the project it would say that there was a missing connection to the invoke node even though I did not touch that part of the application. I would then remove the invoke node, add it again and it would clear the error for whatever reason. I would then build the .exe with the Windows 7 machine and when it would run, the application would crash at the point where it goes to print the spreadsheet.  I got around this by building the .exe with the Windows XP machine, and it worked fine without any issues. However, my Windows XP machine cra**ed out so i'm no longer able to build the .exe on the XP machine .  I needed to make some changes to the .exe not anything involving this section of the code and for whatever reason when the application goes to print it crashes.  I get some criptic crash report from Windows that is pretty much useless.  I think its a Windows thing. This was workign correctly though until I did a build on the Windows 7 machine.

[JordanG]

Have you installed the Service Pack (LV SP1)? There also might be a problem with the .ini file, but my first recommendation would be to install that service pack. You can access it from here:www.ni.com/src

Also, have you turned on highlight execution to solidify the problem is occurring at the invoke node?

Jordan

[Sito_1]

Hello Jordan,

   Yes, I do have the latest updates with SP1. I created a very simply vi that would just perform the actions of printing an excel file while still trying to keep the .vi as similar to the original as possible. The only difference is that I removed a references cluster and just added a reference to a string indicator, so that it would work similar to the original .vi.  I created the .exe tried it on my development computer and it worked fine.  I then moved the .exe to the target machine and enabled remote debugging. When I connect to the target machine and single step through the code, the program crashes as soon as it enters the Printout Invoke node.  This confirms that it is the Printout Invoke node that is causing the program to crash.  As stated before this .vi worked fine when it was built with the Windows XP machine. I also did not touch this part of the code when I had to make changes to the application, yet it is crashing at this point.

[MengHuiHanTang]

I had a similar issue before. My version was I built the exe from a computer with Excel 2010 installed; when you run the exe on a computer with another version of excel, the program crashed where the printout invoke was reached. Upgrading both Excel to 2010 solved the problem. 

Should the version of Excel matter? I did not think so, but it seems that way. 

[Sito_1]

I had my suspicions that this might be the issue. I have already submitted the ticket to our IT department to update to Excel 2007, since this is the version that I have on my development computer. I will try this out and see if this fixes the issue. I will keep you guys posted so hopefully it can help someone else.

-Wilson 

[MengHuiHanTang]

I am almost positive that upgrading to the save version of Excel will solve your problem. Good luck. 

[Sito_1]

Thanks for the input. I just had the Excel on the target machine upgraded to 2007 to match the development machine and you are correct. This fixed the issue I was experiencing. The application no longer crashes when it enters the Print Out Invoke Node. Thank you!

[beaverpelt]

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.