LabVIEW
(Hex 0x4A) Memory or data structure corrupt. Class could not be loaded.
Wild guess - are you using source code control of some sort and have tried to merge changes?
Lvclass files are often interpreted as text by diff tools but are not and then get messed up.
Lvproj and lvlib files are from my experience a little more forgiving, but I'd still be careful.
If that's not the case, do you have a backup from the earlier lvclass file?
@Aliasasil wrote:
Yes, I'm using SVN and tried to merge the changes -> got conflicts in the class and if i try to resolve them, all conflicts are gone but the class is still not loaded in LabVIEW.
Haha! +1 for wild guesses. Sorry for your misfortune though...
@Aliasasil wrote:
The error appeared first when I created a new TypeDef - do you think that the TypeDef might be a problem?
No - probably the problem is the class "merge". I strongly expect that whilst SVN believes it merged the file, it didn't result in a valid lvclass file.
My suggested workflow using Git is as follows. Hopefully it can be adapted to SVN, but I'm not familiar enough with the tooling to give the correct commands (so hopefully you can get the drift and adapt it):
- Checkout the old working copy.
- Checkout any changed files that are not the lvclass file and that you want to keep changed from the new commit
- Alternatively, if this is all of the files but not a class file, checkout only the class file (.lvclass) from the working commit into the new commit, overwriting the broken class
- Carry out a diff if needed between the old lvclass and new lvclass files. You're looking for changes that are readable, primarily VIs that are added/removed. Any unreadable text (lots of random junk) you can ignore - it might be the class icon, or some flattening of the default data, etc).
- By "if needed", I mean this will tell you which VIs were added, moved or removed. You're still keeping the old lvclass in the working directory. If you know what you changed, you can skip this step.
- Open the working lvclass file (via the enclosing lvproj file, or whatever) in LabVIEW. It should load, but if you deleted VIs they will be in the class and "missing" on disk, whereas if you added VIs, they will be on disk but not part of the class.
- Make changes (in the LabVIEW IDE) to the class to make it match the desired state (delete deleted VIs, use the Add > File right click menu to readd new VIs, etc)
- For you, this might include readding the typedef.
- Note that if you changed the class icon, you'll have to change it again, and if you changed default data in the private cluster, that will also need to be checked/fixed. Also any items added to or removed from the private data cluster.
- Save everything, and then commit the new lvclass file.
- Add .lvclass files to the appropriate attribute to prevent future text merges. This will break automatic merging, but is desirable compared to the situation you have now.
- For Git, this involves adding the line "*.lvclass -merge" to your .gitattributes file.
- I believe SVN has an attributes system that can be used to indicate specific files are not text files (even if they are detected to be text). Use this to block the text merges. That link is to a post in a forum thread about source code control - Labview, Source Code Control and Backup.
Unfortunately some parts of this workflow might not map easily to SVN, but I hope it gives at least some pointers.
