Option to disable automatically adding new VIs to open project

[carls__]

If you've got a project open, any new VIs you create automatically get added to the project.  It'd be nice if there was a way to disable this feature.

I find the feature frustrating because:

- I often create new VIs that I never intend to save, just to test out some logic quickly.  However, I can't just close the VI -- I need to go and remove it from the project too -- and this also leads to a dirty dot in my project (and extra work).

- I'd prefer to have full control over which VIs get added to my projects, and where they added within a project.

- If you've got more than one project open, you have to be careful about where you press "ctrl+n" from.

- I've found myself in situations where I close a project after creating a new VI, tell LabVIEW that I don't want to save changes to the project, and by doing so inadvertently lose the code in the new VI because I'd overlooked that automatic association.

[AristosQueue (NI)]

> However, I can't just close the VI -- I need to go and remove it from the

> project too -- and this also leads to a dirty dot in my project (and extra work).

If you never saved it, when you close it, it goes away from the project automatically. Unless you also added it to a library maybe?

My personal take

I think most people would find it extremely frustrating if the VIs they created didn't join the project. That is easily the 90% case during development -- people make new VIs for their code. Adding an option like this for something so rare seems like a waste of developer effort to me. BUT -- important -- that's my personal take. Obviously haven't done the R&D leg work of polling users. I doubt if CEIP tracks how many VIs are created and then thrown away unsaved... we could add code to track that and see how it develops over the next couple years. My bet is that it is rare relative to the number saved and retained. Still -- that's why kudos exist, to proxy for these things.

[carls__]

If you create a new VI, then close it, you're right, it does get removed from the project (which I hadn't realized since I'd gotten into the habit of manually removing them right away to avoid having extra noise in my projects). However, it still adds a dirty dot to the project which makes it easy to either overlook real changes or to cause headaches with source control.  As an experiment, I just created a new VI then closed it without saving, and my project had the following changes to it:

I realize that my techniques may be different than others, but I'd approximate that up to half the VIs I create are temporary for testing something quickly and never get saved. It's something I may do dozens of times a day when in full-on dev mode (and one of the features I like quite a bit about LabVIEW over other languages). I've developed a preference over the years for working outside of projects when possible, and the auto-add-of-VIs-to-projects has been one of the main drivers for this preference.

[wiebe@CARYA]

Make a new VI in a project. Remove it from the project (right click on the project item in the project explorer). Close the project. The VI is still closed, even though it is not in the project! That seems a bit off to me?

If you change the instance the VI is in from the VI (left bottom corner) the VI doesn't close when the project closes, but isn't removed from the project. (I guess that's desirable, just mentioning this FYI.)

[AristosQueue (NI)]

Weibe: Removing from the project doesn't remove it from the project application instance. It still has access to the refnums of the project space, and it doesn't create crossloads of any subVIs. These things are important for most people doing the kind of "quick test" that a never-saved subVI calls for.

[wiebe@CARYA]

>These things are important for most people doing the kind of "quick test" that a never-saved subVI calls for.

Why would you remove the VI from the project if you're doing a quick test?

[AristosQueue (NI)]

> Why would you remove the VI from the project if you're doing a quick test?

So it doesn't get saved with the project (you can save the project without being prompted to save the VI). The entire goal is to not save the VI at all.

[wiebe@CARYA]

I always close the VI if I don't want it saved. That removes it from the project. But perhaps I'm "underthining"?

BTW. Closing the project can lead to unexpected lost work. It happened to be a few times recently, I'm starting to see the pattern.

Spoiler

If there is a VI running with an open front panel (it probably needs to be a clone) closing the project doesn't prompt for saving changes in this VI, or any sub VI it uses that has changes, as they don't leave memory. But when the FP closes (the VI leaves memory), the VI and all subVIs leave memory, and all changes are lost.

I save often, so it doesn't cost me too much, but it's still frustrating. This happens to me because my application has clones as GUIs, and when you minimize them they don't show up in the task bar. So it's easy to forget about them when closing the project, and then to mindlessly close the FP to quit LabVIEW.

Let me know if you need an example. I hope it's as reproducible as it seems.

Probably best continued elsewhere...

[AristosQueue (NI)]

> BTW. Closing the project can lead to unexpected lost work. It happened to be a few times recently, I'm starting to see the pattern.

LV2020? Known issue for which we are trying to get a patch out ASAP. Affects new VIs created from templates -- which means LVOOP suffers really bad because New>>Override is done that way, as well as dyn disp and static disp templates. Use ctrl+s instead of relying upon ctrl+shift+s or the Save Changes? dialog. When the VI is reloaded from disk (instead of being new), the problem is fixed.

[wiebe@CARYA]

Haven't tested this in LV2020. No templates involved. Lots of DD. This doesn't save changes for existing VIs. It sounds like it could be another issue... I'll try to make a SSCCE.

[donkdonk]

For me it is not a rare situation. Indeed it happens quite a lot, that I just want to test something and I have a habit of saving whatever I do on a PC. Too afraid of unintentionally loosing work. That being said, it can also be frustrating to have yet another option to switch something on/off. So I hesitate to kudo this.

But I certainly recognize the 'frustration'.