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.
This VI retrieves all named ranges in an Excel Workbook:
Saved in LabVIEW 2014. Requires the NI Report Generation Toolkit, although you can easily extract the ActiveX property and method calls from this VI if you aren't using the toolkit.
This code addressing this issue is greatly appreciated. I have been able to employ a stand-alone piece of code from the example. The alternate does not employ the Report Generation Toolkit class architecture for code access management. Due to some of the challenges with adding new code to some of the classes, I am having some challenge addressing code portability issues on some attempts at new code (like this).
The question that arises is: "How can new code elements be added to a class, and how can they be made readily redistributable by saving in user directories (outside vi.lib)?" Needless to say, LabVIEW standard libraries and classes will be restored to default state with each LabVIEW installation. This breaks code that then shows that it claims to be a member of a library (or class), but the library does not claim to own it.
Any recommendation on the best place to save this VI to support portability would be welcome.
I have a couple of suggestions, neither of which are that great:
1. Create your own class that inherits from NI_Excel.lvclass. Use the To More Specific Class function on the diagram to cast to your class to call your class-specific methods.
2. Don't mess with classes at all, and just make your own API that uses the references that are output from the Excel Get ActiveX References.vi.
Unfortunately, since the NI classes are locked down, they can't really be expanded on their own, which is why you need to take a more kludgey approach like the suggestions I made above.
