How to commit project changes made via scripting

[Bree_73]

I have a library I'm trying to convert into a project, which has multiple versions where the only thing that differs between them is the containing folder, give or take a couple files in the library.

These VIs have been an absolute crosslinking beast just trying to get a usable project out of it, and it's not even the thing I'm working on (which is an even bigger nightmare of nested stacked sequences). It's a driver to help add functionality to the thing I'm working on, and I'm pretty sure it doesn't work out of the box, hence putting everything into editable VIs.

I think I got it once only to realize I was working on the wrong version, and I got it a second time with the right version only to somehow have all my dependencies revert when I went to use it (although I'm PRETTY SURE I saved everything) and LabVIEW to grey out the "load from selected file" button pretty much universally, and now I'm just totally at my wits end with no idea how to get lightning to strike a third time.

After much trial and error, I've resolved to replace each VI in the project by script. Doing it by hand is mind-numbingly tedious due to the sheer number of VIs I'm working with and how many different ways LabVIEW wants to load them, and it's happened pretty often that my changes have gotten reverted or LabVIEW has stopped me in my tracks by deciding to put some seemingly arbitrary limitation on what files I can and can't move around or load from a new path. It's a fool's errand. It even thinks now that some of the files are still in an LLB, when the path they're at is very clearly not an LLB, but the LLB got added to instr.lib, because that's where the last guy had it, so now I have to put it there too just to tell it to point somewhere else, and now several iterations of all this later neither I nor LabVIEW know what's what or where.

---

Anyways, to the point: the VI I've made works great, each conflict/missing VI is systematically cleared, up until mass replace stops executing. At which point, all of the changes are reverted to what they were before the script ever ran.

I tried all the different modes of ProjectItem:Replace Item, Project: Save, with and without closing and reopening the project after, invoking Application:Project:Close References for all the VIs I edited, invoking Application:Project:Save All, even tried compiling an exe, which went how you'd expect. as in: not at all. nothing happened.

I conclude my mini rant with one question: WHY???? Why is every VI pointing to absolute paths, why isn't there a tool to replace them by the folder like there is with the "Move on disk" function, why is crosslinking so impossible to fix, and why in the world don't my script's changes stay put??? 

---

Thanks for reading, hope someone out there can help.

[crossrulz]

This is the point where I prefer removing every possible version of the code except the one you care about from the disk. Back them up to a removable drive if you feel so inclined. Now load the project and see what gets broken. You can fix things from there, in my experience, pretty quickly (assuming the desired VIs are actually in the project).

And once you get that fixed, learn to use SVN and/or Git. They are a safe way to back up your code, keep history, see what changed between versions, etc. Software Code Control is essential for any development effort. Also, by keeping things in SCC, you can avoid this situation because you can easily control what version you are working in thanks to branches.

[billko]

---

@crossrulz wrote:

This is the point where I prefer removing every possible version of the code except the one you care about from the disk. Back them up to a removable drive if you feel so inclined. Now load the project and see what gets broken. You can fix things from there, in my experience, pretty quickly (assuming the desired VIs are actually in the project).

And once you get that fixed, learn to use SVN and/or Git. They are a safe way to back up your code, keep history, see what changed between versions, etc. Software Code Control is essential for any development effort. Also, by keeping things in SCC, you can avoid this situation because you can easily control what version you are working in thanks to branches.

---

I haven't had that problem in a long while. Because I got burned so badly I learned my lesson early and never forgot it.  😄

[Bree_73]

Thanks for the advice. The git thing actually something I'm working on with the main project. I inherited it from a guy that from started it from scratch over 20 years ago, never once improved his design or learned some pretty essential things about how LabVIEW works, and just plopped everything into one folder and one monster of a main program all throughout. Never implemented any form of version control other than "filename - DDMonthYYYY". So I want to tidy it up a bit before pushing it all up.

I'll go ahead, put everything in to ZIP quarantine, and start this from scratch. I think you're right that a git repository is sorely needed here as well.

[Intaris]

---

@crossrulz wrote:

This is the point where I prefer removing every possible version of the code except the one you care about from the disk. Back them up to a removable drive if you feel so inclined. Now load the project and see what gets broken. You can fix things from there, in my experience, pretty quickly (assuming the desired VIs are actually in the project).

And once you get that fixed, learn to use SVN and/or Git. They are a safe way to back up your code, keep history, see what changed between versions, etc. Software Code Control is essential for any development effort. Also, by keeping things in SCC, you can avoid this situation because you can easily control what version you are working in thanks to branches.

---

Oof, this just conjured up all kinds of horrible memories from LabVIEW 2009. Tried using LVOOP, dabbled with XControls and then caused havoc by trying to use an XControl as a default control for a class. Yes, yes, I did not have a proper versioning system in place and I think I essentially ended up throwing a lot away, but the idea of opening files and classes and stuff one by one to untangle things (making a lot of use of the "files view" in the project) is not a nice one, but sometimes terribly neccessaray.

[crossrulz]

---

@Bree_73 wrote:

So I want to tidy it up a bit before pushing it all up.

---

I wholly disagree there. Just get it in source control. You have something that supposedly works. You want that as your base. You can then do your clean up and commit your updates. When (not if) you break something, you will have something to fall back on.

And if you want to play the office politics game, the commits are a way to show your boss what you have been spending your time on.