Add option to auto-save class file (.lvclass) when a change is made to a class

[egraham]

I want class modifications to be saved immediately. It's very rare that I need to revert any change I have made to a class.

One of the most time consuming tasks is fixing a class after I close and reopen it because I forget to [right-click > save > save]. In fact, I frequently make two source commits because I have forgotten to save the class and I don't realize until after I have made the first commit.

If not exposed through the options dialog, can we at least get a new LabVIEW.ini key?

autosaveClass=True

OR

saveClassOnChange=True

[AristosQueue (NI)]

Certainly this request is viable.I don't know if it'll get enough priority to happen. I will say: you commit without ctrl+shift+s? That's unusual.

[Intaris]

AQ, there are conditions where class changes

a) slow down the IDE

b) don't prompt for saving

I have given my kudos.

[egraham]

I will say: you commit without ctrl+shift+s? That's unusual.

---

I was just speaking with some other devs. It seems over the years I have not gotten over my fear of 'Save All' even when separate compiled code is turned on. I manually choose what to save so nothing ends up in the commit that I didn't touch. Maybe with some committed practice, I can reduce my anxiety and develop new habits. 
🙂

[joerg.hampel]

Seriously? Save all?

[AristosQueue (NI)]

> Seriously? Save all?

I was a full-time G programmer for the entirety of 2021. Save All is what I use in preference to Save always. And, yes, I was using git, so I would've been annoyed if extra things were showing up in my commit lists. With source only properly turned on, yes, it is absolutely what I recommend. How else am I sure that I'm checking in all my changes (unless I quit LV and then click Save All on the Save Changes dialog).

[joerg.hampel]

First of all, I apologise for my previous snappish reply. Thank you, Stephen, for elaborating.

But in all seriousness, I try not to use Save All and that's what we recommend to our customers as well. Just as we would not commit just anything that our SCC of choice shows as being changed or added. Instead, we try (actually, we demand) to carefully curate the change sets, committing only those modifications that actually belong to the intended change.

Now that I think of it, I actually do close the project sometimes to make sure that LabVIEW presents all the modifications, (which doesn't always work as intended) so I can go through them and accept/discard them as I see fit.

It is true though that sometimes, the occasional .lvclass will fall through the cracks and the git commit needs amending - hence my kudo for the OP's idea.

[Intaris]

I actually find the idea of committing without closing LabVIEW a scary thing.

What if there's a changed VI you may want to revert... there is so much which can be associated with a commit that LV just doesnt like.

[wiebe@CARYA]

Never had problems with Save All, except it doesn't always Save All.

I often save all, commit, close. Next day, I open the project and when I close the project it prompts to save changes I didn't make that day. Mostly .lvclass files.

Esp. around build time, I have to save all, close, open, save all close.

[AristosQueue (NI)]

Would you want this option to apply to all libraries (.lvlib, .lvclass, .xctl, .lvsc, .xnode) or just to classes?

[egraham]

I spend most of my time with classes so that's where it would be most helpful.

After your suggestion of using Save All, I tried it out. I made sure all VIs in my project were marked to separate compiled from source, committed a bunch of stuff, then started using Save All. My hope was that it would only alter VIs I had actually changed. One project in LV2020 seemed like it might have been working for me. But another project in LV2021 seemed like stuff was changing that I didn't actually change. Once I saw files getting committed that I didn't actually touch, I gave up on the Save All experiment.