Leaderboard

I know there has not been any activity on this thread for a long time, but thought I'd give my 2 cents on our recent experience. Our (FairlyFunctional and my) medium size Actor Framework (~70 classes total, including messages) project started getting bogged down and updates to class data started incrementally getting longer, as well as moving things around in classes and libraries. In reading through this forum we first moved all of our classes out of libraries, which didn't seem to help, and then recalled Daklu saying something in this forum about clearing the mutation history, which I had to look up. It seems to me that many of the heartaches in this thread were due to mutation history. To delete the mutation history (see this Preserving LabVIEW Class Data whitepaper) you can either edit out the text of the .lvclass file, or rename the class and then name it back. FairlyFunctional added an add right-click option to delete class mutation history idea to the Exchange. We had a fairly large array of clusters that was initialized in the private class data, so every time we made a change to the private class data it was adding another copy of that array to the mutation history (at least that is my guess). If that is the case, another (and better) fix would be for LabVIEW to only update what changes in the class data for the mutation history instead of making a new copy of everything into the geneology. My thought is that previously (pre LV2013?) moving a class out of a library would delete its mutation history, which is why that worked for many people. This idea to warn the user that the mutation history was being destroyed may have prompted the idea to not delete the history when moving it out of libraries? -Sleepy Engineer

Thanks for adding this, what you are saying regarding mutation history makes sense. I tend not to put default data in clusters in the private data, just as I don't put type def cluster constants that do not have default values in a block diagram (see VI Analyzer test for this one). Instead what I do is to add a method to my class that is called "Default.vi", and then generate the clusters there and return the default object that way. This way I don't have to worry about the mutation history and I don't have to worry about the organization of my private class changing. I can see now by your post why this practice inadvertently made things better for me. Thanks, Fab