Problem with Labview Class Corrupting

[prone]

I'm having an issue with a class within a Labview application.

If I save the associated .lvlib then it becomes corrupt and will no longer reopen. Opening it just gives me a message that the class is corrupt and can not be read.
This occurs even if I merely open a working copy and then close it. Labview asks me to save the .lvlib and if I do the corruption happens.

I have narrowed down the problem to

<Property Name="NI.LVClass.FlattenedPrivateDataCTL" Type="Bin">

if I replace the string in this property with the string from the working copy of the .lvlib file then the corruption is fixed.

Obviously this is not a long term fix so any suggestions on how I can find the root of the problem and fix it would be appreciated

[wiebe@CARYA]

There's very little we can do without the lvlib (or lvclass?), and all dependencies, to reproduce this.

It could help if we knew the LabVIEW version, but if you upload code we'll get that information.

[prone]

Thank you for the reply.

Sorry for leaving out key information, I believe it is labview 20.

It is difficult to share the whole class as the dependencies include some proprietary dll files that I am not allowed to share.

I can remove those and upload the class without them if that would be useful?

[wiebe@CARYA]

---

@prone wrote:

It is difficult to share the whole class as the dependencies include some proprietary dll files that I am not allowed to share.

I can remove those and upload the class without them if that would be useful?

---

Iff the problem is still there after removing the dependencies, then yes, that will help.

[prone]

Unfortunately, once I removed the dependency folder the problem went away.

I take it this hints the problem is in that folder?

[Kyle97330]

Did any of the things in the dependent folder have data types that were in the private data of the class?

If so, can you try removing elements from your class private data one by one to see if a particular one being removed solves the issue?

You mention DLL files.  Any chance those are .NET DLLs, and one of the elements of the class private data is a data type from one of those DLLs?  I've had problems with storing .NET data types in private class data before.  What I did for a solution was to internally have the data be a .NET "Object" (i.e. the most generic possible .NET data type) and in the read and write accessors for that data type I would convert it to and from a .NET Object internally so that to all code using it, the conversion would be transparent.

[wiebe@CARYA]

---

@prone wrote:

Unfortunately, once I removed the dependency folder the problem went away.

---

That sounds pretty fortunate to me. Sometimes finding the cause takes much longer, up to infinity.

---

@prone wrote:

I take it this hints the problem is in that folder?

---

If you put it back and the problem is back, it's that folder or that folder in combination with something else (you might be able to delete 'something else' to eliminate the problem).
 

[wiebe@CARYA]

---

@Kyle97330 wrote:

 I've had problems with storing .NET data types in private class data before.  What I did for a solution was to internally have the data be a .NET "Object" (i.e. the most generic possible .NET data type) and in the read and write accessors for that data type I would convert it to and from a .NET Object internally so that to all code using it, the conversion would be transparent.

---

I have some (faint) recollection of this too.

I also remember (faintly) that child classes with could sometimes (by mistake) get an input or output that isn't the parent's type but a .net child of it. This caused some weird effects (crashes etc.). It shouldn't work in the first place.

I've also seen private data corruption to a point it wasn't fixed when changing it from LabVIEW. In the most extreme case I had a class's private data causing random project VIs to to have a dependency on a .rtm file that didn't exist. I had to make a new class, give it the same private data (in LabVIEW) and copy the private data from the lvclass's XML data.

Finding something to reproduce and reduce the problem is a great step towards a solution.

[prone]

I'm not sure about the Dll. But thanks' for the suggestion, something I will dig into.

[prone]

Yes, I meant fortunately slightly ironically, fortunate to have narrowed down the problem. Unfortunate that it is in code that I can't freely share.

But a clue is a clue. Thank you for the pointers