Sleepy_Engineer

You guys Rock!!! So glad you guys experienced this and that google found this thread! Just got my first Mac, bootcamped into Windows 8.1, loaded LabVIEW 2014 and was pulling my hair out trying to figure out why my ctrl+shift+e wasn't working. FWIW, after reading the solution and before reading the rest of the thread I jumped to the control panel, didn't see the keyboard option that was mentioned, so I just added the "United States-International Touch keyboard layout" as a third keyboard option. That seemed to fix it without restarting anything. Not sure of the rationale behind that, but just glad I can move freely around my project again!!! (: -Carl Wecker carl@endigit.com

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