LabVIEW
Save report VI from report generation toolkit is broken
Solved!
Thanks for the response, will have to think about how to go ahead. I'll open a service request to see if NI knows anything more.
In case anyone else comes across this in future, here is what I got from NI together with my own research:
- For LV2016, the VI is saved without the WorkIdentity parameter. As has been mentioned it can be "fixed". Knowledge Base
- LV2017, the VI has been saved with the parameter.
- The parameter appears in office version 1609 and later (released late 2016)
- Any "fixed" version, if built into an exe, will require office 1609 on the deployed system, otherwise the application will crash. Knowledge Base
- "old" version when built into exe will work fine on any system.
- CAR 626944 ("fix" the broken VI, CAR closed fixed 2017) .
- CAR 622996 (exe's break, closed not fixable, workaround match office versions)
Nothing much new, but all confirmed what we know, and no fixes other than the mentioned workarounds.
Interestingly, if you open the 2016 version of the VI in 2017, it is fixed. This is because the VI is recompiled so parameters are retrieved fresh.
I have come up against this issue over the past couple of days as well. I have found what I believe to be a decent workaround for now: changing the method call to SaveCopyAs (right-click on the Invoke Node -> Select Method -> SaveCopyAs). The file will still be saved with the name/location that is passed into the vi. The difference is that the file that is created and open will be a copy and not be saved. I have only tested this with the workbook being left open when the report is disposed (the default is to close the file). This avoids the application from crashing on either Office/Excel configuration.
For some further information that I believe could be helpful:
It seems that it is related specifically to a later version of Office 365. If others could verify that they have only seen this issue with Office 365 updates (and possibly specific versions), that might be helpful.
One of my coworkers has Office 365 installed and does not have this issue. His vi with the SaveAs method is without the additional WorkIdentity parameter and his applications are not crashing when he saves the workbook using the RGT vi's. My version does have the WorkIdentity and does crash when I put it on a different machine with Office 2013/6.
The change apparently occurred sometime after 19 July 2017 and between builds 6965 and 8201.
Oddly enough, both of us are loading the Excel._Workbook.SaveAs Method from "Microsoft Excel 16.0 Object Library Version 1.9" - the same version of the object library, but with different results. When he opens his Class Browser and selects the SaveAs Method (from that library and the Excel._Workbook Class), the WorkIdentity parameter is not there. When I open mine, it is there.
I hope the workaround will help. I don't know if the additional information will help, but that is what I have found out in the past couple of days.
Thanks arteitle! So yours is a Click-to-Run (C2R) application. I thought all of the perpetual Office installs were msi based. So instead of it being related to the version of Office 365, it might be related to the versions > 1609 of a C2R based Office conflicting with the msi based Office installations.
One more difference in my configuration and my coworkers.
The change occurred with version 1609 which is build 7369.2055. So your colleague has the "older" version.
My workaround is to check the build of excel installed (attached VI) then for old versions don't use the save function.
The behaviour below prompts the user to save on close, so all that is lost is the ability to set the filename programmatically without user input, which is annoying but better than not being able to generate the report or just crashing.
Hope this is helpful to someone, it's a pain explaining to managers/customers why suddenly this years release has problems with data export to excel.
As mentioned by JM before, another solution is to do the builds on a VM or other machine with old excel on. I decided not to do this in the end due to the overheads.
Thanks for the workaround on getting the build! I was trying to get something similar but with no luck.
As far as a workaround, I like the SaveCopyAS alternate. It will still save a copy with the programmatic path/filename that you provide. The copy that remains is just that, a copy. For my application, manually entering the filename could easily cause files to be orphaned/missed/miscategorized/lost.
@James_McN wrote:
Ian,
This is great thank you. So am I reading right that from LabVIEW 2017 it HAS to run with the newer Excel build? I would have hoped they might be able to put that flag around the invoke node to handle both somehow otherwise that is a nasty backwards compatibility issue to watch out for.
Cheers,
James
I haven't tested that, but it does look like that might be the case. However, this is the same as what I deal with in 2016 since I recompiled the toolkit (to make it run at all) so it has the new parameter anyway. Guess it will just be left to developers to figure out. SaveCopyAs might be a good workaround, would have to add it into the report gen subVIs though as we can't extract the reference from the class.
