From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application Build Failure on Excel.Print Report call

Solved!
Go to solution

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:

 

WorksheetPrintOut.png

 

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.

Message 1 of 11
(6,767 Views)
Solution
Accepted by TurboPhil

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

Message 2 of 11
(6,766 Views)

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

Download All
0 Kudos
Message 3 of 11
(6,296 Views)

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

0 Kudos
Message 4 of 11
(6,273 Views)

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.

  

0 Kudos
Message 5 of 11
(6,268 Views)

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. 

Message 6 of 11
(6,243 Views)

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 

0 Kudos
Message 7 of 11
(6,236 Views)

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

0 Kudos
Message 8 of 11
(6,234 Views)

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!

 

 

0 Kudos
Message 9 of 11
(6,218 Views)

Been there done that!

 

See this video...

https://www.youtube.com/watch?v=qYAzEpTVsaw

 

How to Fix Your LabVIEW Failed to Compile or LabView Broken Arrow on Compile.

If you have a happy vi running in LabVIEW and it has a happy arrow then it SHOULD compile to an executable. RIGHT??!! NOT... Frequently, especially if the project is LARGE, it will not properly compile!

I show you how you can compile EVEN when you have a broken arrow!

When LabVIEW fails on building an executable it sometimes does not show you WHERE the error is. It also tells you that you need files that you are not using! Go figure! This is because some of the files are ignored that should not be ignored.

If you know how to get rid of the nag screen please let me know by sending an email to me at dave.korpi@gmail.com

This is on a Virtual Machine Windows 7 on VMWARE Fusion 6.02 and the bloody Virtual Windows 7 works better on my iMac than it does on the Toshiba Laptop that I cloned it from!

I use the LabVIEW Service Request System and it is COMPLETELY worth the cost. They are EXTRAORDINARY I would say about 98.7% of the time!

If you liked the video please subscribe to my channel.

Please LIKE this video if you found it useful!

My website if you need Patent Help of engineering help!

http://www.take5inc.com/

Video made with SnagIt

0 Kudos
Message 10 of 11
(5,377 Views)