Jump to content

Library Files Being Modified


Recommended Posts

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?



Link to comment
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?

Link to comment

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?

Link to comment
  • 1 month later...

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?



Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.