LabVIEW Developers Feature Brainstorming

[Noel]

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.

Forum post:   System directory access and LabVIEW directory changes

Proposal:  Access to System Directories from LabVIEW

Questions: 

1. Users need access to the system directories at runtime and at install time.  Besides Get System Directory VI and more entries in Installer Builder, what other features are needed to create applications that disperse files to appropriate special operating system directories?
2. Other comments/questions about the Get System Directory VI?

Message Edited by Support on 08-21-2008 01:42 PM

[jdunham]

---

Noel wrote:

Forum post:   System directory access and LabVIEW directory changes

Proposal:  Access to System Directories from LabVIEW

Questions: 

1. Users need access to the system directories at runtime and at install time.  Besides Get System Directory VI and more entries in Installer Builder, what other features are needed to create applications that disperse files to appropriate special operating system directories?
2. Other comments/questions about the Get System Directory VI?

---

Those are all I can think of, but you should make there there is a way to specify

• the company or application group name
• the application name or nickname
• application instance (if needed)

It seems like you are headed down this route with your Builder settings, but I am worried you will only allow for one level of customized name, where at least two are needed.

If you don't want to provide the last one, I can probably roll that myself (we already do for our shipping application, which can run multiple instances).

[gmart]

I'm not I understand your request. Currently, you can specify the company name and product name in the Installer builder UI. What do you mean by specifying the application instance?

[jdunham]

We can run multiple copies of our LabVIEW application on one computer, saving the results into different databases. (this is an application which runs 24/7).  We save various state files into the data directory, so the applications can be restarted if they crash (which hopefully continues to be rare in future versions of LV).  We also save user preferences. 

Rather than building separate but identical products, we rename the EXE and the INI files so that we can run multiple copies in parallel.  It is not OK for the applications to cross-link their data, so we maintain separate Application Data folders. 

It is likely that you will find this enough of an edge case that we will continue to have to support the folder naming ourselves, and I can live with that, but since you are asking, I am answering.  For most of our deployments, Company Name and Product Name would be sufficient.

[gmart]

I guess I must be dense, but I still don't understand what your request has to do with the application builder settings. If you are copying the EXE's, does that mean you build the EXE with one build specification and then make copies of the output? Where do you get the "company" name and nickname now?

[jdunham]

---

gmart wrote:

I still don't understand what your request has to do with the application builder settings. If you are copying the EXE's, does that mean you build the EXE with one build specification and then make copies of the output? Where do you get the "company" name and nickname now?

---

Yes, we make copies of the build spec output.

Currently we hard-code the company name and we make folders under that using the App.Name property.  This gives us a unique location per instance.  We don't need a fix for this, because it works fine.

But if I start a new project and make one or more executables, I would like to see my data stored in a <Default Data>\<Company>\<Project> folder by default, where <Company> and <Project> are stored in the Build Specification. I don't think built executables should be storing anything in a "LabVIEW" folder and I don't think they should default to storing data directly in a generic Application Data folder.

Thanks,
Jason

[Ben_01880]

This is a fabulous idea. If you have been writing cross
platform code you quickly understand what a great need this fills.
When can I get it?

[AristosQueue]

> I don't think built executables should be storing anything in a "LabVIEW" folder
> and I don't think they should default to storing data directly in a generic
> Application Data folder.

That's a good point. An app build with LV should look like a standalone app, not like a part of LabVIEW. We should double check the path specs with this idea in mind, probably even adding it to the "goals" section.

[tst]

---

Ben_01880 wrote:
.
When can I get it?

---

As the document says: "These changes will not occur in LabVIEW until 2009 or later". Judging by NI's release dates in recent years, that probably means around August of 2009 or 2010.