Norm Kirchner Posted September 25, 2006 Report Share Posted September 25, 2006 I have a project that utilizes a common codebase. I want to use the export distribution to make a new copy in a differnt location of the relevant files in the project, but still use the common codebase that doesn't move on the hard drive. The problem is that if I don't include these common VIs within the distribution, it looks for them in the wrong location after the export has taken place due to relative path linking. Has anyone used this feature enough to understand how to accomplish what I'm trying. -Norm DETAILS: I'm looking to take the VIs within the project and use them as a baseline. So the export will allow the baseline to remain intact, but create a new copy for the person to build off of in a new location Quote Link to comment
Michael Aivaliotis Posted September 25, 2006 Report Share Posted September 25, 2006 Why not just copy the VI's to a new location via file explorer? They'll still point to the common code base. Am I missing something? Quote Link to comment
i2dx Posted September 25, 2006 Report Share Posted September 25, 2006 I have a project that utilizes a common codebase. I want to use the export distribution to make a new copy in a differnt location of the relevant files in the project, but still use the common codebase that doesn't move on the hard drive. The problem is that if I don't include these common VIs within the distribution, it looks for them in the wrong location after the export has taken place due to relative path linking. Has anyone used this feature enough to understand how to accomplish what I'm trying. -Norm DETAILS: I'm looking to take the VIs within the project and use them as a baseline. So the export will allow the baseline to remain intact, but create a new copy for the person to build off of in a new location this is exactly what my "duplicate project tool" tries to do. I am currently working on a LV 8.20 release, which is able to build a "ready to run" LV 8.20 project, too. I could modify my tool in a way, that you are able to select folders, which shall be ignored during the duplication process. If you are working with prefixes, it should work allready. If you are interested, let me know, I can send you the beta version. There is allready a LV 8.0 version in the Code Repository, but I do NOT recommend to use that with LV 8.20. I had plenty work today to fix a lot of bugs ... cheers, CB Quote Link to comment
Norm Kirchner Posted September 25, 2006 Author Report Share Posted September 25, 2006 If I do a simple file copy to a different location on the hard drive, the linking will be wrong. The file links are all relative, no? So if I copy to a totally different branch of the HD it'll be searching for each and every file and even it finds a file named there is always the chance of it being the wrong one. So either I need to have everything already loaded into memory do the copy and then open the files again but that gets sloppy. I could modify my tool in a way, that you are able to select folders, which shall be ignored during the duplication process. If you are working with prefixes, it should work allready. This part would be critical if you include the dependencies within your tool. I would want it to operate like NI export dist panel, where I can select the dependencies item and say exclude all files, that way only the stuff in the project gets copied. Bring me into the beta, I've got a use case all ready to try. Quote Link to comment
Jacemdom Posted September 25, 2006 Report Share Posted September 25, 2006 I have a project that utilizes a common codebase. I want to use the export distribution to make a new copy in a differnt location of the relevant files in the project, but still use the common codebase that doesn't move on the hard drive. The problem is that if I don't include these common VIs within the distribution, it looks for them in the wrong location after the export has taken place due to relative path linking. Has anyone used this feature enough to understand how to accomplish what I'm trying. -Norm DETAILS: I'm looking to take the VIs within the project and use them as a baseline. So the export will allow the baseline to remain intact, but create a new copy for the person to build off of in a new location Putting your codebase path into the search path does not resolve your problem? Quote Link to comment
Norm Kirchner Posted September 25, 2006 Author Report Share Posted September 25, 2006 Not if I want to ensure that there is no potential for cross linking. Quote Link to comment
Ton Plomp Posted September 26, 2006 Report Share Posted September 26, 2006 I have a project that utilizes a common codebase. I want to use the export distribution to make a new copy in a differnt location of the relevant files in the project, but still use the common codebase that doesn't move on the hard drive. The problem is that if I don't include these common VIs within the distribution, it looks for them in the wrong location after the export has taken place due to relative path linking. Has anyone used this feature enough to understand how to accomplish what I'm trying. -Norm DETAILS: I'm looking to take the VIs within the project and use them as a baseline. So the export will allow the baseline to remain intact, but create a new copy for the person to build off of in a new location Correct me if I'm wrong but you want to do this: Copy a set of code This code has some subcode that is fixed in one location (similar to user.lib, why not use these. You can even move user.lib) You do not want to load this subcode via the search path I see really only one option, refer to these subcode via a dynamic path, this VI holds all the sub-vi's in the fixed path. What cross-links are you expecting when using the search path? Ton Quote Link to comment
LAVA 1.0 Content Posted September 26, 2006 Report Share Posted September 26, 2006 Hi, I think that there is a way to achieve this, but I have not verified if I'm correct. Presumably you can write your code as "modules" i.e. put your code into LabVIEW 8.0 libraries (.lvlib). Libraries should work like entities that you can easily include to your project. Store the library into a root directory of that library for example "Module A\Module A.lvlib" Then store all your files that belong to this library under directory "Module A". If you have multiple modules, store each module into a different directory. Now when you move directory "Module A" to new location, it's enough if you include this library in its new location to your project. Then relink the project by pressing Ctrl and then click on run of one of your main executables while having the ctrl pressed. Since library gathers stuff together, LabVIEW doesn't need to search for each individual VI but it knows that the VIs belonging to the library are located relative to the library location. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.