private linker method

[carbonsc]

Hello,

I am currently reviewing some code which has previously been made in which i have found a private method.

I have looked into this method and have not found out much about it but from what i can tell it is core for that the VI is meant to do.

The VI itself clones a VI and its dependancies and adds them all to a new project, and from what i can tell this linker method rewrites the dependancy links to the new locations so that all the dependancies are linked to the new locations.

Is this correct? Does anyone have any information on what this method expects on the inputs in order to operate correctly as i am unable to find any if at all information on it.

If anyone has an example on how to use it correctly that would be brilliant as i don't want to accidentally break this VI while reviewing it.

Leading on from this, is there an alternative which is not a private method?

Thanks in advance

[tst]

You didn't say which specific method is used, so it would be hard to tell. I'm assuming it's Wire Infor To File. I don't personally know the linker methods, beyond knowing they exist, so I wouldn't be able to tell you much anyway other than what I get from looking at them. My guess for that method is that it's simply supposed to allow you to manipulate linkages without loading the VIs into memory, which might be useful if you're processing a large number of VIs.

Assuming you're not, you don't actually need all this. VI paths are stored as relative, so if you just copy all the VIs together and keep their file structure, they will call each other correctly. If they are members of a library or you are renaming them (to avoid collisions between different copies of the template) then you can simply open references to the VIs with VI server and use the Save Instrument method with the new path or the relevant method on the library to rename it. Just make sure to save all the VIs after doing this so that they remember the new linking.

Also, LV 2012 and later have a built in tool for generating templates of projects. You would have to read the documentation to see how to use it.

[carbonsc]

You are correct in saying that i am on about the write info to file method.

When the cloner operates it is pulling dependancies of around 200 different subVIs which are stored in various places. When the cloner runs it consolodates all of these vis into a project structure and then updates these paths to match acordingly. Unfortunatly relative paths would not work in this case.

This was the reason that the cloner was originaly made.

[tst]

Like I said, if you want to change the relative paths or library memberships, the proper way to do this is to open reference to all the VIs and call the save methods on them with the appropriate paths. To get all the VIs, you can start with the top level VIs (note that that dynamic calls are also top level) and recursively use the Callees[] property on each VI to get all its children (probably ignoring VIs under the LabVIEW folder, since you would usually not want to touch those).

It's also advisable to also save all the VIs again in the end even if you did the renaming bottom up, because you could have some unexpected dependencies, so it's good to cement it once you're done.

[rolfk]

In addition to what tst said, this method, while existing since the times LabVIEW has the built in VI server interface, was broken in the past two times by NI. Since it is not public, NI reserves the right to change this method at any time for any reason they see fit and in both cases in the past they did not develop the usual safety net around that change. When LabVIEW changes a public VI server method or property in any way that can cause trouble it either gets a new method or property with the changed signature while the old method is marked depreciated (and gets a red header in newer LabVIEW versions) or there is actual code added to the mutation engine to mutate VIs on upgrade to the newer LabVIEW version by adding conversion nodes or VIs into it.

Nothing of this happened for this method. If your code called it and you upgraded to the new LabVIEW version you could load the VI hit the run button and wonder about the crash dialog as the method got fed with a data structure that did not match anymore the internal memory layout as expected by this node. So private nodes are definitely not something you should use lightly. They will come and bite you sooner or later in ways that are more than a little nasty.

Making a method or property public or not is not only a decision about hiding some functionality from the user. In fact that is only for very few of them the real reason. The main reason are two things normally:

1) Documentation: Writing documentation costs time, writing documentation for external users costs double and triple as much time as it requires extra reviewing, translation and more reviewing.

2) Once made public and documented it is many times more expensive to make a change to it. If they break a private method in a new LabVIEW version it is only their internal users, who needed that for a specific tool to be shipped with LabVIEW, that they will upset. A public method that breaks in the slightest could mean that one of the big key customers hits into it and goes after NI in ways where the usual flames in the forum from users who have hit a bug look like sunday prayer.

extra reason) This method changes the entire linking information for all involved VIs directly without much of safety checks. That's the main reason it is faster than doing it properly through the public VI server interface. Writing incosistent information back into the VIs could render them so messed up that fixing them after that is more or less beyond reasonable effort. So if you plan to use this method, make REALLY REALLY sure that your code calculating the new relationships is working correctly. And don't use it on original source code ever. If it is not backed up, in version control or a copy of the original code don't ever let your VI using that method even near to that code!

NI made a lot of effort to try to prevent cross linking of VIs with the change to projects in 8.0 and improved on that continously since. This method can create very nasty cross links if you are not careful, which can get your code into a total mess.

[carbonsc]

I have spent today experimenting with this function (with dummy code definalty not source code 😉 and i belive i have figured out how it works (the new vi heirarchy looks to be pointing in all the correct locations and it all opens and saves without errors.

i undertsand that this function can change at any point and that is really should not be used for production use however i have found that after cloning and saving the vis that the paths are not relative and they still point back to the original source files.

i am unsure if its just me not opening and saving them correctly. Another aspect which i think could be affecting this is the way that i traverse the vi heirarchy. Is there a specific direction i should take (top down?) in order to clone the vis and to ensure that the dependancy paths update because as it currently stands i can only update these links using the linker function 😕

[rolfk]

---

@carbonsc wrote:

i am unsure if its just me not opening and saving them correctly. Another aspect which i think could be affecting this is the way that i traverse the vi heirarchy. Is there a specific direction i should take (top down?) in order to clone the vis and to ensure that the dependancy paths update because as it currently stands i can only update these links using the linker function 😕

---

Well hierarchically you should definitely save from bottom up as otherwise the top level VIs will be indeed saved with the paths pointing to the original locations and saving the lower level VIs later to a new location will not update the path references in the already saved higher level VIs.