Trouble passing boolean references to VI's when program is compiled, but works fine in development mode.

[SunshineDesign]

I made a poor man's test sequencer and use a boolean reference to pass into my test vi's the reference to an abort button to determine if the vi is to run or select case thru to abort the test. This all works fine in development mode. In compiled mode I have one or 2 tests that crash the program at the start of the vi. I have been able to determine it is due to the pass parameter of the boolean abort button reference. When I remove that pass parameter from the test troubled with it, the problem goes away. I get no errors on this pass parameter in development mode and only see it on some of my tests (not most of them) in compiled mode when I run the executable. Anyone have any ideas how to resolve?

[Mark_Yedinak]

You could use a notifier instead. The other option would be to use a Functional Global in place of the reference. It is not a very robust design to pass UI references to lower level subVIs. The subVIs/tests should be agnostic with respect to the UI and not depend on any element of it. You need to pass state information. If this is static (set only prior to running the test) then simply pass the value in. If it is dynamic (can be set during the execution of the subVI) use a notifier, queue (if you need to buffer data) or a functional global. Any of these methods is much more flexible and will avoid the issues you are running into.

[SunshineDesign]

Thanks Mark. I consider globals bad programming. Not being able to pass the boolean reference as a pass parameter that other languages handle fine, would seem to point to compiler issues and deficiencies to me. Especially given that it works fine for over 90% of the test vi's and only fails with 2 test module vi's. I'll have to look into notifiers and see if that helps. I do have to have this a dynamic variable as opposed to static, as I have to pass into the test vi's the boolean value in real time as it is pressed.

[aeastet]

You could also use events. They are easy to use once you understand them. I think that would also be a good way to go.

[Mark_Yedinak]

I don't advocate or use global variables either. However a functional global (sometimes called an action engine) is not a traditional global variable. It is a subVI with an uninitialized shift register to store the data and an input which indicates what action should be performed. In the simplest case this is just initialize, read and write. However you can perform more complex tests or operations on this data as well. An action engine can be viewed similar to an object. You have a single instance that has data and methods you can perform. However action engines (unless implement using LVOOP) do not support all of the other features of OOP classes and objects.

The fact that your program crashes tells me that in some part of your code your reference is becoming invalid. You could be running into a case where the reference is being automatically closed and released due to the order of execution of your code. It is not an inherent flaw in the language.

In addition, a good application architecture will try to decouple the UI from the processing tasks. Passing references to items on the UI to low level tasks creates an explicit link between the UI and the processing task. It couples them together and makes reuse more difficult. Creating an API (via events, notifiers, queues or an action engine) decouples the processing task from the UI. It makes your application code more flexible and easier to reuse.