Library Files Being Modified

[mje]

An issue I've been dealing with for some time is LabVIEW modifying libraries I generate when it shouldn't. This happens to me quite regularly, and was discussed recently. I'm starting a new thread not to derail the old one...

Background: I have a re-use library which defines classes which are extended in other libraries or projects. Often when working on my projects, my re-use library files will be modified despite me having never explicitly done so.

I just got this when I was doing a checkin:

At the bottom of the list is a modified file in the LabVIEW.Messaging.2.0 library, which should not have been changed. I was working on classes extending from those defined in the messaging library, but never made explicit changes to the messaging library itself. There is a single offending line in the class file:

Working copy (truncated):

<Property Name="NI.LVClass.FlattenedPrivateDataCTL" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!%"15F.3

Base copy (also truncated):

<Property Name="NI.LVClass.FlattenedPrivateDataCTL" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!%!I5F.3

Both class files (just the XML, none of the supproting VIs etc) are attached, v10.0f2. Though not in this case, I've also seen dynamic dispatch VIs from the base class become modified as well. Am I the only one that sees this behavior?

classdiffs.zip

-m

[crelf]

You need to set the following to TRUE:

• LabVIEW Options > Environment > Saving VIs > Treat read-only VIs as locked
• LabVIEW Options > Environment > Saving VIs > Treat read-only VIs as locked > Do not save automatic changes

Once you've done that, support this.

[Aristos Queue]

You need to set the following to TRUE:

Thanks, Relf. That tells me that something is causing the parent to recompile. But what? And why? In other words, it's a harmless change, and we're recompiling to exactly what we were before the recompile, but we shouldn't even have to do the recompile.

> I was working on classes extending from those defined in the messaging library

Any idea what you were actually editing?

[mje]

You need to set the following to TRUE:

• LabVIEW Options > Environment > Saving VIs > Treat read-only VIs as locked
• LabVIEW Options > Environment > Saving VIs > Treat read-only VIs as locked > Do not save automatic changes

Once you've done that, support this.

That would be ideal, maybe I should start locking my library VIs when I'm not explicitly modifying them. My current practice does not have them set to read-only.

Any idea what you were actually editing?

Yes, I was moving a property and associated methods from one class to a more generic class. In this case, the hierarchy looked like this (from least specific to most specific):

Messaging:MessagePump < Messaging:View < HDXView < HDXMainView.

Note the last two classes are not part of the re-use library. I removed an element from HDXMainView's data cluster, and put a replacement in HDXView (a literal cut and paste, if I recall). The element had static accessor VIs which defined a property, these were moved to the base class. Some dynamic dispatches had to be modified/deleted/added to either class. I'll point out that while the intermediate View class was not modified, it also doesn't implement any of the dynamic dispatches that were worked on, which might be a clue?

[Aristos Queue]

You mentioned properties were involved. That *might* be addressed in the 2011 beta. Are you part of the beta program?

http://ni.com/beta

[mje]

You mentioned properties were involved. That *might* be addressed in the 2011 beta. Are you part of the beta program?

http://ni.com/beta

Unfortunately no, this product will have a release date that predates the 2011 release, so I don't have that luxury.

[mje]

Just thought I'd add the issue persists in 2010 SP1.

[Wire Warrior]

Okay this brings up a question I was having the other day. I can see how the treat read-only VI's as locked would solve this problem but how are you setting the VI's to read-only when you emplace them? We use VIPM to distribute our reuse libraries but I see no way to set them to read only on import. I have considered generating a VI that could be run post install of the VI package that would set the VI's properties to read only. Is there a better way that I am missing?

Thanks

Jason