Expected behavior for base classes when editing extending classes?

[mje]

This has happened to me a few times now, but I'm not sure this behavior is intended or a manifestation of larger problems I've been running into with the IDE.

I have some reuse libraries that have classes in them, these are actual lvlib files that have some public classes exposed.

In a project, I include the libraries, and extend from the classes defined in the livlib files. After working for a bit, I go to do a save all, a bunch of stuff saves. I then go to commit my changes to source code control, and find that my re-use libraries have been modified. So I then shut LabVIEW down, revert the library changes via my SCC, then open up the project to confirm everything is a go, then do the commit proper.

Why is it LabVIEW is modifying the base classes? Is this normal?

When this happens, the library files that are modified are always the base lvclass file and some of the base's dynamic dispatch VIs that I was overriding in the extending class. I'll re-emphasize I had not explicitly made any changes to the base class. Reverting the base class files via SCC has no apparent effect on the project: loading the project again does not trigger any automatic changes to the base files. They just seem to get saved for some reason the first go around?

I don't know what to expect by posting this, it seems I've run into so many weird things in my dealings with LabVIEW OOP, there must be something I'm doing that is just wrong. But surely I'm not the only one though?

-m

[Daklu]

This has happened to me a few times now, but I'm not sure this behavior is intended or a manifestation of larger problems I've been running into with the IDE.

It could be a known bug, depending on what changes LV thinks it made to those classes.

I get it a lot when I am saving my project. Classes I haven't edited are asking to be saved again. Usually the reason is "An item in this library has moved" or "An attribute of this library has changed." I've done binary diffs on the scc copy versus the newly saved copy and they are identical. I just ignore them now, though it is a bit of an annoyance.

[mje]

I've been ignoring them too for ages, mostly because I was developing the libraries in tandem with the core project. But now I'm trying to pin down one of the libraries to a static tag, so I explicitly don't want my library to change, even if it is one of these phantom changes. I've done similar comparisons and seen the same results as you, Daklu.

It would be neat if I could include a library as read only, to force LV to discard any changes it thinks it makes, might be an idea exchange entry brewing...

[asbo]

It would be neat if I could include a library as read only, to force LV to discard any changes it thinks it makes, might be an idea exchange entry brewing...

This is pretty basic, but any chance you've tried setting the files read-only on disk? A less convenient option might be locking diagrams without a password?

[jdunham]

This happens to us all the time too. Like Daklu says, the lvclass files themselves don't change, and consequently they claim to need saving every time the project is closed. Therefore it's just LabVIEW putting an erroneous 'dirty flag' on the lvclass. We don't bother to save them, but it is quite annoying.

[mje]

This is pretty basic, but any chance you've tried setting the files read-only on disk? A less convenient option might be locking diagrams without a password?

That thought scares me, I don't know if I trust the IDE not to get annoyed when it attempts to modify a read only file. Besides, the library still gets worked on from time to time, I'd rather not have to reset the flags each time.

Therefore it's just LabVIEW putting an erroneous 'dirty flag' on the lvclass. We don't bother to save them, but it is quite annoying.

I'm aware of those changes, and have posted about it before. But in this case, the files actually are changing, hence the need to do SCC reversions. Next time it happens, I'll run diffs and see if there actually is any difference beyond timestamps I suppose.

[jgcode]

A less convenient option might be locking diagrams without a password?

I don't recommend this for distributing reusable code.

This was a feature I thought I wanted for ages - but the VIs/Classes then don't recompile when you install in a future version of LabVIEW.

On the flip side, if you could install, unlock, mass-compile, save all, lock - then that may be desirable.

[Daklu]

I'm aware of those changes, and have posted about it before.

See... I *knew* I had read about that problem somewhere on Lava...

I mentioned it because... you know... just in case you forgot you had already posted about it.

[asbo]

That thought scares me, I don't know if I trust the IDE not to get annoyed when it attempts to modify a read only file. Besides, the library still gets worked on from time to time, I'd rather not have to reset the flags each time.

Quite commonly I'll modify in-memory a VI I don't have an SCC lock on. It's actually convenient because for changes I don't intend to retain, I never lock the file - when I close out the IDE (or File > Save All) I can tell it to save everything. It saves everything it can, and then the prompt comes back up for files it couldn't save. I then hit Don't Save and that's that

I don't recommend this for distributing reusable code.

This was a feature I thought I wanted for ages - but the VIs/Classes then don't recompile when you install in a future version of LabVIEW.

On the flip side, if you could install, unlock, mass-compile, save all, lock - then that may be desirable.

Yeah, I did think about that after I posted and the way you describe - in an atomic sequence - is really the way I meant. I think scripting might be the only way to mass-lock or mass-unlock, though.

[jgcode]

Yeah, I did think about that after I posted

You're ok - it was me who has been running my mouth requesting a useless feature and creating workarounds for the last x months!