LV2009 SP1 doesn't include VI when subVI node set to load on call

[george seifert]

I was getting a weird error about a null window from an executable that worked fine under LV2009. The VI that caused the problem was setup with the subVI node setup in my main VI to load when called and then close when done. I ended up having to specifically include the VI in the executable build. I never had to do that before.

Something to watch out for in your builds.

George

[gmart]

I think the behavior you are seeing is due to the creation of a new build specification (which you did coincidentally in 2009 SP1). I created a new EXE build specification for a caller VI that has a subVI configured as you specified. Going all the way back to LabVIEW 8.2, when a new EXE is built, the resulting app returns the error you referenced. This actually makes sense since the application builder does not know that the VI needs to have its front panel included because of that setting. Adding the VI as Always Included forces the front panel to be kept and thus the application works.

It's possible that in the "working" situation, the building specification in that project has the setting such that the front panel is kept on that particular VI.

[Mellroth]

I think the behavior you are seeing is due to the creation of a new build specification (which you did coincidentally in 2009 SP1). I created a new EXE build specification for a caller VI that has a subVI configured as you specified. Going all the way back to LabVIEW 8.2, when a new EXE is built, the resulting app returns the error you referenced. This actually makes sense since the application builder does not know that the VI needs to have its front panel included because of that setting. Adding the VI as Always Included forces the front panel to be kept and thus the application works.

It's possible that in the "working" situation, the building specification in that project has the setting such that the front panel is kept on that particular VI.

Possible workaround:

Usually when I create VIs that I know will be used as dialogs, pop-ups etc. I go into VI properties and de-select the "Allow user to close window". Doing this seems to force LabVIEW to believe that this is a front panel that should not be removed during builds.

I have suggested to R&D the addition of an option in the VI settings that would allow me to explicitly state that the FP should be kept during builds, instead of having to specify this in every build or use workarounds like this. It seems kind of silly that the option to keep a front panel is only available in the build specifications when a VI could be used in several builds.

/J

[Rolf Kalbermatter]

Possible workaround:

Usually when I create VIs that I know will be used as dialogs, pop-ups etc. I go into VI properties and de-select the "Allow user to close window". Doing this seems to force LabVIEW to believe that this is a front panel that should not be removed during builds.

I have suggested to R&D the addition of an option in the VI settings that would allow me to explicitly state that the FP should be kept during builds, instead of having to specify this in every build or use workarounds like this. It seems kind of silly that the option to keep a front panel is only available in the build specifications when a VI could be used in several builds.

/J

Another workaround I use occasionally is to include a property node that access some property of a front panel element. This is a NI sanctioned way going back to LabVIEW 4 or so and I suppose they will not break that intentionally, even-though they may wish they never had used that workaround anywhere.

[Yair]

I suppose they will not break that intentionally, even-though they may wish they never had used that workaround anywhere.

I have reason to believe NI has a test in their suite to ensure this works in an executable, so hopefully they shouldn't break this even unintentionally.