Modify the DQMH folder hierarchy structure?

[FabiolaDelaCueva]

Hi,

First, the NI moderators have enabled again the Kudos feature on the documents section of this forum. This means you can vote again on your DQMH feature requests by giving kudos.

We have traditionally kept discussions regarding the different feature requests separate from that document. This is to make it easier to track.

I wanted to hear more about what LabVIEW developers using DQMH think about the following feature request:

"

Mike_CCM requested: 

"Folder Cleanup

Currently all vis and typedefs are just thrown in one folder. It makes it difficult for a TestStand developer to find a particular request he is interested in. I suggest a cleanup in folder structure on the hard drive  to reflect the one of the library.”

an psmorris said:

"Backing up Mike CCM's comment on folder cleanup - We're using VIPM to turn modules into installed packages with the public API (only) exposed through the palettes. It'd be really handy to have all the public API VIs (and .ctls) in their own "public API" folder to make it quicker to create the palettes in VIPM (just get rid of everything expect the public API folder! 

You could possibly go one stage further and sub-folder the "built in" API VIs (e.g. show panel, hide panel etc) and sub-folder "user created" API calls... but that may be a step further than absolutely necessary (I get why sticking close to a flat hierarchy is sensible too!)

Paul”

"

When we designed DQMH, we agreed that all file organization would take place directly at the library level on the project in LabVIEW. Leaving a flat disk hierarchy makes things a lot easier with version control and also encourages the developers to not rely on disk organization and instead go directly to the project for that. 

We had worked on projects that had folders called "private", "public" to separate VIs by scope and we didn't want to have something similar on DQMH.

An alternative to the requests above would be to explore the possibility of a post install VI for VIPM build spec that would create the palettes automatically.

For TestStand, create a scripting tool to add items to the Templates Pane.

Thoughts?

Fab

[mRadziwon]

---

Leaving a flat disk hierarchy makes things a lot easier with version control and also encourages the developers to not rely on disk organization and instead go directly to the project for that. 

 [...]

 For TestStand, create a scripting tool to add items to the Templates Pane.

 Fab

---

I agree with the statements a lot. For me, having TemplatesPane populated with correct calls would serve the purpose for  which I have initially proposed "restructuring" of the folder structure.