03-10-2008 09:48 AM - last edited on 08-21-2008 01:42 PM by Support
Note (August 2008): Thanks to all of the users who have provided feedback on these proposals. At this time, NI is likely to proceed with the proposed LabVIEW API to access system directories. However, NI has suspended plans to implement the proposed changes to the LabVIEW directory structure. The proposed LabVIEW directory changes originated internally based on anticipated demand for NI to adhere to Microsoft Vista's directory recommendations. Since imposing a new directory structure impacts Alliance members and many of our other customers, we have decided to suspend these changes until there is a greater customer demand.
After reading over the proposed directory changes, what concerns do you have? What changes are you interested in learning more about? Are you concerned about any specific use cases being considered as part of the proposed directory changes?
03-10-2008 04:10 PM
various directories under <LabVIEW Application Data>To:
<LabVIEW User Documents>\PluginsCan you go into any more detail on the <LabVIEW Public Documents>\Plugins folder sub-structure and functionality as it would relate to specific directories and functionality currently under <LabVIEW Application Data>? For example, the section mentions the LabVIEW/project folder (which adds Tools>> menu-launch items). However, it does not state exactly how this will look under the new Plugins directory.
<LabVIEW Public Documents>\Plugins
And, here are some specific questions:
- <LabVIEW Public Documents>\Plugins\Menu-Launch (menu-launch items subfolders go here)
- <LabVIEW Public Documents>\Plugins\Menu-Launch\File (File>> menu-launch items)
- <LabVIEW Public Documents>\Plugins\Menu-Launch\Help (Help>> menu-launch items and help documentation)
- <LabVIEW Public Documents>\Plugins\Menu-Launch\Tools (Tools>> menu-launch items)
- <LabVIEW Public Documents>\Plugins\Menu-Launch\Edit (Edit>> menu-launch items)
- <LabVIEW Public Documents>\Plugins\Menu-Launch\Window (Window>> menu-launch items)
- <LabVIEW Public Documents>\Plugins\Menu-Launch\Browse (Browse>> menu-launch items)
- <LabVIEW Public Documents>\Plugins\Call-backs (all of the call-back items that are currently in the LabVIEW/resource/plugins folder)
03-10-2008 06:10 PM - edited 03-10-2008 06:12 PM
03-10-2008 06:26 PM
03-10-2008 10:03 PM
|Default Data Directory||N/A||Per-user directory for version-independent files containing program output data (e.g., LVM files).|
|Default Data Directory||C:\Program Files\National Instruments\LabVIEW <ver>|
03-11-2008 09:22 PM
I'll respond re: the plugins directory later. Right now I'd like to comment on the "Default Data Directory" and "Default Directory". These are two separate file constants. I have two mistakes in the tables -- I mistakenly called the "Default Data Directory" the "LabVIEW Data Directory". I also mistakenly call the "Default Directory" the "Default Data Directory" in one of the tables. Yikes! I'll fix this tomorrow in the published document.
Part of the reason I'm suggesting we get rid of one (the Default Directory), is because it is easy to confuse the two....
The original intended use of the "Default Data Directory" is the default save location for the output of Express VIs like the Write to Measurement File VI. I still believe that for the Express user, that we should have a default save location and it should be under the User's directory. Hence, I'm proposing we keep the "Default Data Directory".
03-12-2008 02:29 PM
I am in total agreement on this. Labview's default data directory has always been problematic, and I am glad you are taking this on. I think it's fine if you deprecate a folder, but I'm not sure why it would be included as an option in your new API.
The original intended use of the "Default Data Directory" is the default save location for the output of Express VIs like the Write to Measurement File VI. I still believe that for the Express user, that we should have a default save location and it should be under the User's directory. Hence, I'm proposing we keep the "Default Data Directory".On the other hand, the "Default Directory" has all sorts of problems. As pointed out, User files should never be written to the Program Files directory. So, the current description and current disk location are at odds with future plans to disperse files to directories based on user access. So, I suggest deprecating the "Default Directory" constant.Thanks for catching the mistake.- Noel
03-12-2008 03:26 PM
03-12-2008 04:19 PM
Noel wrote:The reason that these two directory constants need to be discussed as part of this overall LabVIEW directory change game plan is because both return paths that relate to the current LabVIEW usage. And, hence, people want to know how these path constants are impacted.
As far as I'm concerned, there is no good reason for its continued existance except to support backward compatibility for someone who probably doesn't realize there are better choices that are self-documenting.
Right, but LV will still be supporting the old primitives which returned those paths (for compatibility). I'm suggesting you don't allow the new directory API to return those paths, so that no one is tempted to keep using them in new code.
Noel wrote:After the directory reorganization, the intent is for the Default Data Directory ( User Documents/LabVIEW Data) to be the default location for data files like .lvm files. The plan is for features that currently use this directory for application files, such as Auto Save, Error Logs, etc -- to move their files to a version-specific directory under the User Application Data directory.
So did you understand what I was getting at?
The current behavior of LabVIEW can be illustrated with the following steps.
Most new programmers and new users just use the folders LV suggests, so they tend to store their data and source code in the same folders, which I think is terrible. My point is that you can make this API which is nifty, but since most people just use the dialog boxes, you are not going to get 'correct' behavior unless you fix the file dialog start path at the same time.
- Make a new VI, and drop Write to Text File on the diagram, with some ordinary text input.
- Save the VI somewhere.
- Run the VI. The file dialog box will start in the same folder where you saved the VI. (I think this is just terrible)
- Save the text file in some other folder
- Create a new VI
- Save the new VI. The "Name the VI" file dialog box will start in the same folder where you saved the text file (I think this is just terrible).
When I say "most people" etc. I mean that as a consultant I have seen many different labview programs by many people, and it is somewhat rare for novice programmers to wire in a path at all (if wired, it's almost always a path constant, which I'm sure you've noticed too).