From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
01-18-2011 11:46 AM
I posted in the main groups looking for a way to retrieve the VI history/comments/metadata without loading the whole tree. Someone mentioned there is a method that is either used internally by the LV team or has been developed that will get this data without trying to open dependencies (I am working on a custom SCC tool that won't have access to the whole tree).
Is that available?
Thanks!
Jed
Solved! Go to Solution.
01-19-2011 01:07 AM
JedDavidow wrote:
Someone mentioned there is a method that is either used internally by the LV team or has been developed that will get this data without trying to open dependencies
Jed
😮
I have never heard of that but if it exists I am really interested as well. Can you give the link to that discussion please?
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
01-19-2011 02:27 AM
Here's the link, not much there:
01-19-2011 10:31 AM
01-19-2011 12:47 PM
JedDavidow,
I sent you a private message concerning this topic.
-Trevor Christman
01-24-2011 10:59 PM
Thank you for the snippet. However, I get some funny behavior. When I run it standalone, there is no problem. When I work through a loop of paths and it encounters the history of a Vi with no entries it will return the history of the previous VI in the list. So I get a list of histories with duplicate entries (this isn't true every time- after a while it will return a correctly blank history. And as far as I have seen, it doesn't return an incorrect history for a VI that has a non-null history).
I'll keep playing and posting what I find
(tried in 8.6 and 10.0)
Jed
01-25-2011 02:25 AM
More data: I can't seem to get it to work reliably when built into an EXE. When running in a loop, I get this error on SOME of the calls (don't get this error when running in dev mode). Woth or without the error, I never see any history.
01-25-2011 09:33 AM
Hey Jed - I'm sorry you're having problems with this one. Unfortunately, this is basically the LabVIEW analog of "rooting" your iPhone - it might work, and it might void your warranty
There are a few methods and properties which exist in LabVIEW but aren't exposed to users. Sometimes specific functionality was needed for a LabVIEW feature, but this functionality was never intended for end users. Hence, it is not tested for
Also, this type of functionality would most likely be left out of the LabVIEW Run-time Engine. This is simply to reduce the size and overhead of the RTE.
01-25-2011 09:49 AM
Jed,
I might be way outdated, as I usually work still with LV 7.1.1, but from what I have read here I believe you should access the 'History:EntireText' property of the VI in question. You can access this via VI-server even when the VI in question is not executable.
But I might have missed the core of your Q!
01-25-2011 10:53 AM
Hi Lul,
I am actually trying to create a utility EXE that is called by my source-control software on the server when files are submitted. It would read the comments since the last submission and include them in the SCC database.
Since I want this to happen on the server (no Labview IDE on it), there is no way to ensure that all the dependencies will be available when the file loads. When you open a reference to a VI in VI server, it loads all the dependencies too (although you can add flag bit 0x20 to supress the search box, you cannot specifiy that you want VI server to load the VI without its subVIs, controls, etc).
Ideally I woud have created an EXE to do this, which would be invoked by the server when a submission was made. However, none of the methods out there work in the RTE (not even the standard call you mentioned). So unless they publish the data format in the binary file (not gonna happen), someone reverse engineers it (I ain't gonna do it) or they update the calls to work under the RTE, I might have to run the LV Dev environment on my server.