LabVIEW crashes when modifying OOP parent class private data control or typedef contained in that control

[AnthonV]

I've been seeing strange behaviour when I modify the private data control of a class, especially if it is a parent class.  It seems that those changes are not always propagated to all the VI's in the project.  This sometimes causes my project to crash with an exception error, or sometimes the problem is more subtle as it will simply write data to the wrong elements in the control (when bundling/unbundling).

I solve the problem by opening the typedef or class control by itself (i.e. not as part of the project), and then saving it.

The next time I open the project all problems are solved.  This is a difficult error to track down but I now know to keep a list of typedefs or class controls that I have modified (using subversion helps here), and then when this strange behaviour or crashes happen, I simply close the project and open each modified typedef or class outside of the project and save them individiually.

Anyone seen something like this too?

[mikeporter]

I have not seen that and use classes a lot. What version of LV are we talking about? OS?

Mike...

[AnthonV]

Ive seen it on 2012 and 2013.

[mikeporter]

What Operating System?

Mike...

[AnthonV]

I develop on windows 7.

[mikeporter]

Hmmm.... Have not seen what you are describing -- though occasionally I will see a class that appears broken until I open it by itself outside the project.

• How large is your application?
• How many classes do you use?
• How extensively do you use classes in the application?
• Could you post a screen shot of your project and how things are arranged in it?
• Does the problem seem to be related to any particular class or group of classes?
• Have you tried mass-compiling your code?
• Are the VIs set to separate the object code from the source?

Mike...

[AnthonV]

I wouldn't say it is very large or special.  I do use a lot of data value references and variants and multiple class instances running on different core (on a quad core).  It doesn't seem to happen if I deploy the application to a RT target, but it does happen on Windows.

• 40MB on disk, 64 typedefs, 500 vi's 
• About 20 classes
• All functionality and data are encapsulated in classes
• Screenshot of top-level (doesn't really give away much does it?)
• 

[mikeporter]

Well, the big difference is that I don't put everything in classes - negatively impacts readability . That may make a difference.

Mike...

[AnthonV]

Thanks for the suggestion but I doubt that moving code from a class vi to a non-class vi will make a difference. I suspect it has more to do with the member data of classes than with the member functions and I say this because the problem normally happens when I modify a class control and never when I modify class vi's.
It must have something to do with the labview environment not propagating the control change to all the references to it in the project.

[mikeporter]

That is certainly possible. Something I do a lot is create a "catalog" VI. It holds one instance of every top level VI. With this open changing datatypes can be much easier. Still, I have never seen LV not update typedefs.

If you nail-down the cause for sure let us know.

Mike...