I forsee nothing but problems with that. You move a file into an autopopulating folder and then it has to be resaved when the library is next opened. What happens if the file was part of another library? You should be very explicit with library members. Autopopulating folders is not that.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Autopopulating folders and libraries hate each other at the technical root. One is an organizational view-my-files sort of thing. The other is an "I claim ownership and actually modify the namespace of the files" sort of thing.
I have a hard time imagining any development system under which just copying files into a directory would be a good way to declare "I have edited these files to be in a new namespace."
I agree with Aristos that having the files automatically included is probably not desired in many cases, but I also know that many teams follow the "folder hieararchies should match namespace hierarchies" philosophy so I can understand the tension.
Personally I have struggled with this in the past and I would have been happy if there was an easy "refresh from disk" folder option that would then allow me to quickly get new files into the library and I could remove them if I didn't want them there. It would be even nicer if items on disk that aren't in the library but are under this folder would show up in a ghost mode showing they are there but are not in the library. Essentially, make it easy to handle the case described by this idea but without the auto-magic part.
- Be abble to distribute LabVIEW funtions in order to use them in TestStand actions or step types.
- I don't want that TestStand steps point on a VI hierachie
- I would like like, to call LabVIEW code as Shared Library
... so ... i decide to test the packed library ... which, i think, is exactly what i need (A list of VI's in a unic compiled file ! ... a DLL, with a LabVIEW interface )
And then, i discovered that, to create a packed library, i had to create a LVLIB !!!
My LabVIEW code is structured in a LabVIEW project with autopopulated VI's folders.
I tryed to drag VI in a LVLIB ...
and then i get troubles !!!
Where are my VI's saved ?
It's a question of source code managment !
So i decide to transfer all my VIs in the library ...
and i discovered then that autopoulating is not allowed.
What i would like is ....
- To code my VI's in a standard LabVIEW project in which i can test them ...
- This project could include one or more windows applications
- And some of the VIs could be distributed externaly to TestStand, as a packed library.
- And i don't want to duplicate VI's in many projects !
In dot Net i would have create ...
- A library assembly
- A Windows form application which use this assembly
- An an assembly for TestStand (Which also use the library code) How can i do this properly with LabVIEW ?
My idea was ...
- A project containing my libraries and the code for my windows application
I am now taking off my LV R&D hat and putting on my LV user hat. This is me speaking as an individual, not as a member of R&D:
I recommend you stop using autopopulating folders. In my experience, they are a flawed concept, not in how NI crafted them, but in the constraints that they place upon code. Autopopulating folders make assumptions about the structure of your disk reflecting the usage of your code, an assumption that is rarely true for any but the most trivial of applications. Let the VIs be saved any which way on disk and use the logical relationships provided by the project's virtual folders and by the libraries/classes to map out your software. When you are finished with development, or periodically during development on a larger project, you can run a tool to rearrange your disk layout to match your virtual hierarchy, or just use a source distribution build spec to create the distribution with the layout that you want to see.
Many people both within and without NI believe autopopulating folders are great tools that should be used heavily. I'm not in that camp, and if you're having trouble because you're fighting with them, I suggest you stop using them... it may very well be that your development style, like my own, does not play well with that feature.
I use autopopulating folders for source code managment purposes !
I want to be sure that the VIs of my project (Excepting VI comming from external libraries) are contained in a directory, which i can place under source code management, zip ...
Using Virtual folder is for me dangerous !
How many time i get LabVIEW projects, by mail, by FTP ... from collegues, with missing VI's !
Using autopopulating folders is my way to solve this problem !
Perhaps highlighting VI's not saved under the project hirarchie will be an other possible solution ?
(It could be a good idea ! )
As an example, for many years ago, with an old version of LabVIEW and and old version of Windows, a LabVIEW application was using a VI which was located in the windows dustbin !
The application worked fine during months without problem.
Then, someone made some cleaning of the computer, by removing the files in the dustbin !
=> The application was then out of order !!! And the missing VI was not saved in source code management because it was out of the application source folder !!!!!
With autopopulating folders, this is the kind of problem i want to make disapear !
a) No, they aren't links, because those aren't disk folders. The non-autopopulating folders in the project tree are just organizational tools. In that sense, *EVERYTHING* in a project is just a reference from the project.
The virtual folder is the default because the project is intended to be used only with virtual folders. The autopopulating folders came along later in response to user requests. They aren't a good idea but -- exactly like global VIs -- we added them because a large number of customers thought they were what they wanted and a sufficient number of users could use them without being burned.
b) The tool you want for managing your directories is the Files View of the project. Open your project window and hit Ctrl+E or click on the tabs in the project window. This shows the on-disk organization of your files. Use this instead of autopopulating folders.
Thanks for your reply. .. i don't aggree with it, but thanks a lot for your explanations.
The Ctrl+e file view show too much not interesting files ... links to dll, libraries ...
And because my labVIEW project is under a SVN structured tree, the visualization is too complex.
The file viewer should show a relative tree, starting from the project root.
My need is to have a structured rapid access to my source code ... Ctrl+E is not a solution !
for the virtual folders, my hate to this feature is because i had to maintain projects created with them !
- The project was structured with virtual folders, pointing only to top level VI's
- So, when you open for the first time the project, it seemed quiet simple to maintain !
But ...
- The subvis was to be accessed through Ctrl+E or windows browser ...
- And the VI's were all located in horrible full directories, non structured ... a kind of Bin !
If you structure your project with virtual folders, why couldn't it be the same structure on disk !!!! I think it's completly dangerous to have a difference between the 2 structures.
I would aggree with you, if you could place more than one time a VI in multiple virtual folders.
So it could be a way to say, for this purpose i need to use these VI's ... But it is not so !
An as i say, my use of autopopulating folders is, at the begining, a need of source code management ! Which is not covered by virtual folders !
...