Fab

Congratulations!!! Thanks for the compliments, I am blushing So, I guess I will see you at one of the CLA Summits next year? Fab

Thanks for posting this, I will be looking for improvements when I start working on larger projects in LV 2012.

The project was in LV 2011. I will start using LV 2012 in my next project. Could you post the CAR number, so we have something to mention if we see this behavior again in 2012? Thanks, Fab

My bad... you are right, I should not assume, because when... Hopefully NI finds what the problem is and it gets addressed. Fabric's idea in the idea exchange is getting more kudos, that is encouraging.

Thanks for sharing the video. It is good to know that I am not imagining things My classes also have static accessors available through property nodes. I wonder if that could be the problem.

I am sorry to report that I had the opportunity to show this problem to AristosQ... and Murphy did its thing and LabVIEW worked as expected and I couldn't reproduce it while he was watching ... I guess is like when you take the car to the mechanic. But I will keep jing ready and make a video the next time it happens. Thanks, Fab

Well, just tried it and of course it does pull most of the project in the dependencies. Which makes sense, because part of the classes inside each library are the classes intended for the messages for each library. Each message class is a child of the generic message class. So, all the libraries end up having some connection. Now, I have this problem not only when I edit the messages classes, but also when I edit other classes in the libraries that might be unique to each library. It is looking like the solution is to do away with lvlibs. However, like I said before, I really like the organization they provide. Plus it makes it easier to turn each lvlib into a separate VIPM package. Fab

I think I can reproduce it with my code fairly consistently. I don't have the time now, because I am in the middle of a deadline... but when I am done with this project I will try to send my code to NI. I will keep you posted.

I have not tried that. I have tried opening the library by itself and I have the same problems.

I have experienced this a lot in the project I am working on. At first I thought it was something I was doing wrong. now that I found this thread and the discussion in the AF community, I realize that there is something going on with the IDE. I continue to have my classes in lvlibs. The architecture I am working on has multiple QDMH with their messages wrapped in classes. Not as fancy as the Actor framework but it gets the job done. I like to have the messages inside the lvlibs. So, my workaround has been: Remove the class from the library save Disinherit the class save modify private data wait for LabVIEW to take its time (if it is too long for my taste, couple of minutes, then I kill it and try again). modify accessors/property nodes save inherit again move back into lvlib some times I don't have to kill LabVIEW at all, other times I have to. I have even gotten into a situation where I have two machines working in parallel and see which one can do the modification without choking. Even after all this, I won't give up on using classes nor lvlibs. I like the project organization, name spacing and dynamic dispatch too much. But I wonder if I would be so optimistic if my project was larger. Glad to know I am not the only one. I hope Fabric's idea gets a lot more kudos. Fab