You can't add Auto-Populate folders in classes.

[Michael Aivaliotis]

In LabVIEW 8.5, you can't add Auto-Populate folders in classes. Aeee Caramba!

[Ton Plomp]

QUOTE(Michael_Aivaliotis @ Sep 7 2007, 09:42 PM)

In LabVIEW 8.5, you can't add Auto-Populate folders in classes. Aeee Caramba!

Well, I think this is intended behaviour (good you didn't post on the bug forum)

At this meeting Jeff also presented an extended version of the 'Three little bears' post on EyesOnVIs.

Some things were mentioned, each VI-path should only be once in a project.

So if you have d:\sub.vi inside an lvlib/class and the class is inside the project a 'auto populating folder' of d:\ will not show sub.vi.

I'm thinking of use cases for using auto-populating a class (it's the same for XControls so I assume it goes for lvlibs and xnodes as well).

It will recompile the VIs in such a folder!

So it will claim every VI that is copied into the folder, I assume this can be very unwanted behaviour.

Ton

[LAVA 1.0 Content]

I remember hearing the statement that 'a class can contain nothing other than the immediate members of its class' in response to, why can't I put a child-class as a child under the tree and I believe that what you are trying to do violates that. But that being said, i agree that I should be able to put items as children in a class in a project tree.

[Michael Aivaliotis]

I know this is not a bug and I'm not talking about child classes. I just want to create a VI and when I save it in the defined AP folder the class will include it. Is that so bad?

[Ton Plomp]

QUOTE(Michael_Aivaliotis @ Sep 8 2007, 12:12 AM)

....

Is that so bad?

No it's lazy, but that's why we are programmers :laugh:

Ton

[Aristos Queue]

QUOTE(Michael_Aivaliotis @ Sep 7 2007, 05:12 PM)

I know this is not a bug and I'm not talking about child classes. I just want to create a VI and when I save it in the defined AP folder the class will include it. Is that so bad?

"Is that so bad?" Yes. You're asking for the logically impossible.

A: "Everything in this directory is going to be owned by this class."

B: "Um, but you put the .lvclass file itself in that directory."

A: "Oh, well, I mean that the .lvclass will own everything in the directory *except* the stuff that it can't possibly logically own."

B: "Oh, that's better. I'm sure our documentation folks will love explaining that one, but with enough psycodelic drugs, I'm sure they can do it. ... But wait, what about the files that you copied into that directory by hand when LV wasn't even running?"

A: "Well, the class should own those too."

B: "You mean when you open the VI, LabVIEW should be smart enough to know about all possible libraries in the ENTIRE harddrive to know which ones are monitoring which directories so that when you say 'File>>Open' on one of those VIs, LabVIEW just mystically knows to open the library as well and edit it to own the VI?"

A: "Well, yeah."

B: "Fine. We'll just load ALL THE LIBRARIES ON YOUR DISK into memory every time you launch LV. That way we'll know which libraries are monitoring what."

A: "Oh. Uh. Um... "

I could go on. I fought hard against autopopulating folders. They are a false hope. But users demanded them. And so we have them. And I even got involved with the team that worked on them to try to make them work with libraries (and thus, by extension, classes). But there are so many logical contradictions and impossible relationship resolutions that I just can't believe it'll ever work out.

[Jim Kring]

QUOTE(Aristos Queue @ Sep 10 2007, 07:39 PM)

I fought hard against autopopulating folders. They are a false hope. But users demanded them. And so we have them. And I even got involved with the team that worked on them to try to make them work with libraries (and thus, by extension, classes). But there are so many logical contradictions and impossible relationship resolutions that I just can't believe it'll ever work out.

IMO, autopopulating folders address use cases for building EXE's (and other build targets) that might be better addressed by more features in the build rules system. In the LabVIEW project environment, anything that is a Dependency (or not explicitly in the project under My Computer) is excluded from the build. This requires that anything that should be included in the build be put under My Computer, and the only "dynamic" way to do this is with auto-populating folders. This is in contrast to the way builder works -- e.g., it supports the use of wildcards and recursion when declaring support files and automatically includes every VI dependency unless it is found under an Excluded directory (the user can define which directories to exclude).

:2cents:

[gmart]

QUOTE(Jim Kring @ Sep 10 2007, 10:02 PM)

In the LabVIEW project environment, anything that is a Dependency (or not explicitly in the project under My Computer) is excluded from the build.

I don't understand what you mean. Let's say you have a top level VI which has a hierarchy. The only VI in the project under My Computer is Top-Level.vi. If you create an executable build specification and build it, the hierarchy of Top-level.vi will be included in the build. Now, if what you mean by dependency are support files that are not part of a VI's hierarchy, then there is a mechanism to manage that. You would need to add them under My Computer and then make them "Always Included". I'm not clear as the what behavior is lacking.

[Jim Kring]

QUOTE(gmart @ Sep 11 2007, 05:20 AM)

I don't understand what you mean. Let's say you have a top level VI which has a hierarchy. The only VI in the project under My Computer is Top-Level.vi. If you create an executable build specification and build it, the hierarchy of Top-level.vi will be included in the build. Now, if what you mean by dependency are support files that are not part of a VI's hierarchy, then there is a mechanism to manage that. You would need to add them under My Computer and then make them "Always Included". I'm not clear as the what behavior is lacking.

I misspoke (it was late when I wrote that). Yes, all VI dependencies are added to the build. What I meant to say is that in order to target VIs to a specific destination, they must be beneath My Computer (and no longer in the Dependencies). And, as I mentioned, OpenG Builder treats support files differently from VIs and is able to handle wildcards and recursion. For example, you can do things like add a folder's contents recursively, but exclude any folders that are named ".svn" or "CVS". You can also do things like include all files named "*.ini" from the "configs" folder. These sorts of features are the reason why people want autopopulated folders in the LabVIEW Project Environment.

I mentioned to Christina R. that "Smart Folders" (similar to Smart Groups in Apple XCode, iPhoto, iTunes, etc.) might be the best way to achieve this easily in the LabVIEW Project environment -- they allow you to define a rule set that determines whether items are members of the group and appear in the folder.

[uPDATE] One more thing that I found annoying is that LabVIEW's builder only lets you exclude vi.lib, user.lib, and/or instr.lib. It would be nice to add other locations, for example, paths beneath the project root. This would facilitate building plug-in architectures and components that are linked to each others sources in the same project structure, but are built seperately.

Thanks,

[gmart]

QUOTE(Jim Kring @ Sep 11 2007, 10:30 AM)

I misspoke (it was late when I wrote that). Yes, all VI dependencies are added to the build. What I meant to say is that in order to target VIs to a specific destination, they must be beneath My Computer (and no longer in the Dependencies).

Ok, that makes more sense. You can send dependencies to a defined destination, but it has to be ALL dependencies. You can't pick and choose. To do that, you need to move them under My Computer.

QUOTE

And, as I mentioned, OpenG Builder treats support files differently from VIs and is able to handle wildcards and recursion. For example, you can do things like add a folder's contents recursively, but exclude any folders that are named ".svn" or "CVS". You can also do things like include all files named "*.ini" from the "configs" folder. These sorts of features are the reason why people want autopopulated folders in the LabVIEW Project Environment.

I'm not sure if your use case is THE reason for autopopulating folders. I think a major motivation was being able to have some control from the project over the physical location of files. The current implementation may not be the ideal for all users, but I think it helps many who have wanted the feature.

Even without autopopulating folders, you can still achieve what you want. It requires you to structure the project such that all .svn files are in one folder. That way you can control the actions of those files via the folders settings in app builder. The organization is pushed to the project versus having options in app builder. Again, perhaps not the ideal case, but it is doable.

[Ton Plomp]

QUOTE(gmart @ Sep 11 2007, 06:02 PM)

Ok, that makes more sense. You can send dependencies to a defined destination, but it has to be ALL dependencies. You can't pick and choose. To do that, you need to move them under My Computer.

I'm not sure if your use case is THE reason for autopopulating folders. I think a major motivation was being able to have some control from the project over the physical location of files. The current implementation may not be the ideal for all users, but I think it helps many who have wanted the feature.

Even without autopopulating folders, you can still achieve what you want. It requires you to structure the project such that all .svn files are in one folder. That way you can control the actions of those files via the folders settings in app builder. The organization is pushed to the project versus having options in app builder. Again, perhaps not the ideal case, but it is doable.

One thing to mention, I discussed this with Jeff Washington (who created this feature), and he mentioned that hidden items aren't added to auto-populating folders. Normally the .svn folder is hidden and the same goes for .scc files (from MS sourcesafe). I think a lot of Source Code Control related files/folders are hidden.

Ton

[Aristos Queue]

QUOTE(Aristos Queue @ Sep 10 2007, 09:39 PM)

I could go on.

Going through my notes, I found another impossible situation. Recall that in my previous post I said there was a problem of figuring out which library owns which directory when we load a VI from that directory into memory. Suppose we did solve that problem. In that case, suppose user creates Project A and in that creates Library Q to watch directory X. Save All and close all. Now user creates Project B and in that creates Library R to watch the same directory X. Now, when VIs are placed in that directory, which library should they become a part of? And before you say, "Well, LV should just prevent two libraries from ever owning the same directory X," consider the case of saving a backup copy of your library. You do "File >> Save As >> Unopened Copy" and save your library off under some other name. Do you really want us to prevent that because that would create two libraries owning the same directory?

Why do G programmers want autopopulating directories and libraries to work together? The issue comes down to wanting to make it easy to associate a given VI with a given library and, in the same step, keep the disk structure up to date. I wish that we'd found something that worked more to integrate the "ownership" relationship with the "disk hierarchy" relationship. Autopopulating folders does nothing except automate a small part of the disk maintenance problem. They're nice for a flat VI hiearchy if you're the kind of user who moves VIs around a lot, breaking apart hiearchies and extracting VIs out of the middle of projects, without using LV to move them. But they don't (and can't) help with library organization at all.

[Tomi Maila]

QUOTE(Aristos Queue @ Sep 11 2007, 09:58 PM)

I wish that we'd found something that worked more to integrate the "ownership" relationship with the "disk hierarchy" relationship.

It's late and I may not be thinking clearly anymore. However I think TortoiseSVN and presumably other source code control software successfully solve a similar problem. When using TortoiseSVN you define a file system folder and all it's subfolders to be under source code control. TortoiseSVN doesn't automatically syncrhonize the content of all folders with the SCC server. Instead, the user needs to commit changes. Committing changes forces TortoiseSVN to syncrhonizes the folder structure with the source code control. TortoiseSVN uses hidden folders to store information about it's previous known state.

This is actually not that different from the problem of LabVIEW libraries needing to keep in sync with certain folders. LV could rely on hidden files to find out to which library current folder belongs to. When a file is added to the folder, it's not automatically added to library. Instead it needs to be synchronized with the library, which could be manually executed or automatically occur when the folder owning library is opened. The hidden files could be used to specify which library owns a folder so that only a single library could own a folder. If a VI is opened in an owned folder, then LV could simply check from hidden files who owns the folder and open the owner as well should this be required.

EDIT: I actually should meet Jeff W. tomorrow, let's see if I come up with something interesting to ask from him.

[Justin Goeres]

QUOTE(Tomi Maila @ Sep 11 2007, 01:27 PM)

This is actually not that different from the problem of LabVIEW libraries needing to keep in sync with certain folders. LV could rely on hidden files to find out to which library current folder belongs to. When a file is added to the folder, it's not automatically added to library. Instead it needs to be synchronized with the library, which could be manually executed or automatically occur when the folder owning library is opened. The hidden files could be used to specify which library owns a folder so that only a single library could own a folder. If a VI is opened in an owned folder, then LV could simply check from hidden files who owns the folder and open the owner as well should this be required.

This brings up an interesting issue to me (apologies if this is kind of a thread-jack).

In the olden days, we developers did almost all of our VI file management on disk. The only thing LabVIEW did to try and help out was to (attempt to) relink files when they weren't in their expected locations. While this was occasionally infuriating, we all learned to work with it and the world kept spinning.

Ever since LV80, we've got a whole bunch of new wrinkles in how we manage our VI (and related other) files. Classes can contain VIs, Classes can contain folders, LVLIBs can contain VIs, LVLIBs can contain classes, virtual folders can have access scope, projects can contain everything, some things can contain non-VI files, etc. (and I've left out XControls entirely, being somewhat of a n00b in that area). Part of what we're seeing with things like auto-populating folders are (I hope) just the growing pains of working in this New World of project-based LabVIEW development.

I'd like to believe that all of these changes lead to some Grand Unified Theory of LabVIEW LVPROJ/LVLIB/LVCLASS organization, but it's not clear to me how it should all work together. That leads me to make decisions in my project organization that sometimes turn out to be really suboptimal later on. Is there some great exposition of What The Project Environment Truly Does For Professional Developers that I've just missed out on? Is the users' demand for Auto-populating folders (and NI's apparent acquiescence to it ) just a symptom of a situation where nobody really understands exactly what the Project environment is really for?

[Aristos Queue]

QUOTE(Justin Goeres @ Sep 11 2007, 04:19 PM)

Grand Unified Theory of LabVIEW LVPROJ/LVLIB/LVCLASS organization

My personal vision? There cease to be files on disk representing VIs, libraries, projects, etc. Instead there is a database (MySQL, Oracle, whatever). That database contains all the VIs for a given EXE -- whether that is LabVIEW.exe or your built application/DLL. To move stuff from one machine to another, you would export VIs from the database to a portable database file, and then import them into the database on the other side. Source code control on the local machine is just transactions on the database. Source code control to a remote depot would involve LV brokering the transaction via temporary files to "check out, import, export, check in."

No more save changes dialog asking you about Defer Decision

No more cross-linking

No more expensive disk tracking in the project window (new in 8.5)

No more having to load all your VIs into memory for them to be aware of edits to subVIs

No more confusion about disk hieararchy vs project hierarchy vs ownership hierarchy

No more files changing when LV isn't looking

No more confusion about which files are loading from where

No more surprise missing files

This might seem radical, but this is exactly the approach taken by some of the recent JAVA IDEs.

[Yair]

QUOTE(Aristos Queue @ Sep 12 2007, 12:59 AM)

No more save changes dialog asking you about Defer Decision

No more cross-linking

No more expensive disk tracking in the project window (new in 8.5)

No more having to load all your VIs into memory for them to be aware of edits to subVIs

No more confusion about disk hieararchy vs project hierarchy vs ownership hierarchy

No more files changing when LV isn't looking

No more confusion about which files are loading from where

No more surprise missing files

Ooooooooh, sounds great.

Can you tell us if your vision is being given any serious considerations within NI?

[Aristos Queue]

QUOTE(yen @ Sep 12 2007, 07:55 AM)

Ooooooooh, sounds great.

Can you tell us if your vision is being given any serious considerations within NI?

Serious insofar as a lot of us are intrigued, but as a real project, no. It's a pie-in-the-sky thing for the time being, something for *years* down the road. A lot of these sorts of big dreams take many years to work through. LV classes were being dreamed about 2 years before a team formed to work on them, and then took 6 years. LV FPGA was demo'd at NI Week five years before it released. The LV project window was the result of many years of customer feedback and a couple years of development time. These bigger shifts take a while. And this one is definitely in the idyllic "wouldn't that be nice" stage where it has only positives and no real negatives. ;-)

[ragglefrock]

QUOTE(Aristos Queue @ Sep 12 2007, 09:53 AM)

Serious insofar as a lot of us are intrigued, but as a real project, no. It's a pie-in-the-sky thing for the time being, something for *years* down the road. A lot of these sorts of big dreams take many years to work through. LV classes were being dreamed about 2 years before a team formed to work on them, and then took 6 years. LV FPGA was demo'd at NI Week five years before it released. The LV project window was the result of many years of customer feedback and a couple years of development time. These bigger shifts take a while. And this one is definitely in the idyllic "wouldn't that be nice" stage where it has only positives and no real negatives. ;-)

This is also the approach taken by many new programs such as iTunes and iPhoto (Apple isn't the only one with the idea). They really don't want users thinking about the file structure at all. That should be completely hidden. For instance, if I crop a picture in iPhoto, iPhoto will make a backup of the file in case I want to revert the changes a month later, and put the backup in some folder on disk I've never heard of. But I don't think about all this complicated file management, I just hit Undo.

On the other hand, there's a (potentially) big difference between users of basic Apple programs and engineers, who might want that integral control over everything, even if it hurts them.

[Jim Kring]

QUOTE(ragglefrock @ Sep 12 2007, 08:38 AM)

On the other hand, there's a (potentially) big difference between users of basic Apple programs and engineers, who might want that integral control over everything, even if it hurts them.

A) LabVIEW was a Mac program before it was a Windows program.

B) Do LabVIEW user really want integral control over everything?

[Justin Goeres]

QUOTE(ragglefrock @ Sep 12 2007, 08:38 AM)

On the other hand, there's a (potentially) big difference between users of basic Apple programs and engineers, who might want that integral control over everything, even if it hurts them.

I'm a user of basic Apple programs (or I was until my last Mac gave up the ghost), and an engineer. I don't particularly want "intergral control over everything"; I just want to solve problems. That's what has made programs like iPhoto and iTunes so successful. They really help (the targeted) users solve problems with photo/music management. I don't think it's that LabVIEW developers want so much control over everything (but see below). It's that our problem space is (or seems to be) much broader than that served by applications like iTunes or iPhoto. Add to that the fact that we're accustomed to "rolling our own" solutions to VI/project management (see my earlier post about the Olden Days), and you end up with a sort of inherent distrust of anything NI does that comes and mucks up our status quo.

QUOTE(Jim Kring @ Sep 12 2007, 09:36 AM)

B) Do LabVIEW user really want integral control over

everything

?

All I ask for is enough control over everything such that all bugs in the development environment have workarounds. I'm looking at you, LabVIEW 8.5 Build Specification .

[Jim Kring]

QUOTE(Justin Goeres @ Sep 12 2007, 11:08 AM)

(see my earlier post about the Olden Days)

You're hyperlink should be...

   http://forums.lavag.org/You-can-t-add-Auto-Populate-folders-in-classes-t9019.html#entry35624

not...

   http://forums.lavag.org/You-can-t-add-Auto-Populate-folders-in-classes-t9019.html#35624

Could this be related to the recent forum problems?

[uPDATE] hmmm... you're link is fixed now. Strange.

[Justin Goeres]

QUOTE(Jim Kring @ Sep 12 2007, 11:30 AM)

[uPDATE] hmmm... you're link is fixed now. Strange.

I was fixing it while you were posting . I could go into why I ended up with the wrong link in the first place, but it's really not that interesting .

[Yair]

QUOTE(Jim Kring @ Sep 12 2007, 07:36 PM)

B) Do LabVIEW user really want integral control over everything?

No. I would be extremely happy if LV knew how to manage all the VIs\libraries\classes\contols\etc. on its own without the need for creating files for them and managing those files.

Granted, there would be many many problems to solve (e.g. backward compatibility, DB corruption, SCC integration, code distribution), but it sounds like a potentially great solution to many problems.