LabVIEW would crash when adding a control to global variable.

[ephuong]

LabVIEW 2013 crashes when adding a control to a global variable front panel. 

Error: DAbort 0xE95059A8 in BlockNodeStateFactory.cpp.  Version: 13.0.1f5.

I had copied the same test program to another PC with the same result.

Both PCs has Windows 7, 64 bit OS.  I had conducted a mass compile of the program but the problem still persists.

[ephuong]

I was able to add a boolean when I opened up the global variable.  However, after the global variable was saved with the boolean added, when I open up the main program, LabVIEW crashes with the same error code and message.

[Bob_Schor]

Gee, it sure would be interesting to have the VI that causes this interesting behavior to look at, try, play with, etc.  We'd need the actual VI, of course, not a picture, which might miss a significant piece of the puzzle.  Please attach the VI.

Bob Schor

[dmysliwiec13]

Are you able to recreate this crash? If so could you provide some steps to do this?

[ephuong]

Yes.  The main program contains global variables to the input.gbl.vi attached.  By double clicking on any global variable, would bring me to the input.gbl.vi.  When I add a control to the input.gbl.vi, LabVIEW would crash.

[ephuong]

I had attempted to open the program with LV 2015.  Project would open fine, but I had to relink all the dependencies to the LV 2015 libraries and upon replacing the dependent VIs, LV 2015 crashes with the same error.  Each time it was a different VI that causes LV to crash.

[ephuong]

Does anyone know if this has to do with the tab control?  I removed the tab control from the VI and was able to add controls without LV crashing.

[RavensFan]

I was able to open this in LV 2014, add stuff do it, and drop it into a blank VI without any crashing.  What is interesting is that the global just shows up as boolean called STK7.

But I have to ask, what the heck are you trying to do here?  That is a super complicated "control". Global variables were never meant to be that complicated.  And certainly not meant to have a tab control.

I can certainly believe the tab control is causing the problem.  A tab control is really more than a control.  It is meant more to be a container and organizer of other controls on the front panel.

[ephuong]

The tab control function only as a container to organize the controls, in this case all the controls are global variables.  This is a legacy software that we are required to support and update.  We have another program simular to this one with even more controls that are global variables, organized with tab control and I have no problem adding controls to it.  It is probably not related to the limitation of the number of controls allowed on the tab order.  Any idea as to what could be causing the crash?

[Norbert_B]

This look more like an attempt for an "easy debug panel". What strikes me is the fact that you mix classic controls with modern controls and type-defined enums (which you did not attach).

While LV allows you to implement something like this (front most the fact that you will access all these items using global variable nodes all over your project), it is one of the worst things from code style guide standpoint. In fact, you open all doors for race conditions (sporadic functional misbehavior, bad performance impact, ...) and make the code very hard to maintain. IT IS NOT RECOMMENDED TO DEVELOP LIKE THIS.

Also it is not recommended to add additional dots into filenames.

I cannot reproduce the crash with LV 2016, but keep in mind that due to missing type defs the global is 'broken'.

Are you working in the context of an project (lvproj file)?