04-29-2020 09:37 AM
I cannot figure out how to delete a VI from a project that also removes it from the hard drive.
Selecting a VI in a project and hitting the delete key only removes it from the project but leaves it on the hard drive. Right clicking on the VI and hitting remove does the same thing. Holding keys like shift delete also does not work. In fact the IDE further agitates the situation by asking me to save changes to the VI as most VI's I work with are in a class. (Due to the VI being removed from the class)
Why is this a problem. When working with a big project with many VI's and source control. Developers end up checking in a lot of VI's that are not used. These VI's lead to confusion when someone starts looking for something. Maybe I just like to have things orderly on the hard drive as well.
04-29-2020 09:48 AM - edited 04-29-2020 09:49 AM
That's an excellent reason why you need to do what you need to do. However, the only way I can figure out is to do them manually. This is how I approach the issue:
Sorry that all I could offer you was a workflow to what you are probably doing anyway. 😞
EDIT: There's all sorts of reasons to not make the deletions atomic, so you probably won't see it implemented any time soon.
04-29-2020 09:58 AM
If you use auto-populating folders you just delete the file from disk and the project updates appropriately but I don't use them unless I'm working on a project where the original programmer used them.
I follow the same workflow as Bill. Every so often I will also drag the folder containing my project source from windows explorer into my LabVIEW project. You will get some warning/error dialog letting you know that most files are already in the project but if you press okay LabVIEW mimic the folder hierarchy on disk and bring in any files that were not already in the project. I find that this lets you locate any orphaned files without too much effort.
04-29-2020 10:31 AM
@Rannoch wrote:
Why is this a problem. When working with a big project with many VI's and source control. Developers end up checking in a lot of VI's that are not used. These VI's lead to confusion when someone starts looking for something. Maybe I just like to have things orderly on the hard drive as well.
I use Subversion with TortoiseSVN as source code control software. I installed TSVN Toolkit from Viewpoint System in LabVIEW, which gives you a 'Delete' option in a right click menu in the LabVIEW project explorer.
Using the 'Delete' option the VI is deleted from project explorer, deleted from hard disc and is marked for deleting from Subversion with your next commit.
04-29-2020 10:34 AM
@UliB wrote:
@Rannoch wrote:
Why is this a problem. When working with a big project with many VI's and source control. Developers end up checking in a lot of VI's that are not used. These VI's lead to confusion when someone starts looking for something. Maybe I just like to have things orderly on the hard drive as well.
I use Subversion with TortoiseSVN as source code control software. I installed TSVN Toolkit from Viewpoint System in LabVIEW, which gives you a 'Delete' option in a right click menu in the LabVIEW project explorer.
Using the 'Delete' option the VI is deleted from project explorer, deleted from hard disc and is marked for deleting from Subversion with your next commit.
You know, I use that toolkit, also, and I never thought of doing that!
04-29-2020 10:40 AM
@Jacobson-ni wrote:
If you use auto-populating folders you just delete the file from disk and the project updates appropriately but I don't use them unless I'm working on a project where the original programmer used them.
I follow the same workflow as Bill. Every so often I will also drag the folder containing my project source from windows explorer into my LabVIEW project. You will get some warning/error dialog letting you know that most files are already in the project but if you press okay LabVIEW mimic the folder hierarchy on disk and bring in any files that were not already in the project. I find that this lets you locate any orphaned files without too much effort.
I look in the dependency folder to see if there's stuff in the project's physical folder, but that's tedious, and also inaccurate. I like your way, better. 🙂