globals or property nodes to quit sub VIs... Heretical thoughts!

[BlueTwo]

I have a main vi that has an event structure and is used to call several sub vis that have their front panels displayed on a sub-panel on a tab page. The sub vis are called using the VI>Run VI invoke node and use a Static VI reference. Some of the sub VIs contain while loops and run indefinitely until the main application is closed. I need to close these sub VIs neatly (not just use the abort node).

I have two solutions: One uses property nodes Panel>Controls to supply an array of the control references in the subVI. A loop is used to index the array to find the reference for the 'Stop' control and a boolean high is written to stop the sub VI. This is duplicated for each subVI (though could be a single occurrence and indexed). The second solution uses a single global  variable, written to once in the main VI and read once in each subVI.

I know using globals in many situations is considered poor practice, and to-date i have followed the mantra that globals should be avoided unless there is no other way. Considering the amount of unintuitive code this approach is generating (given invoke and property nodes hardly constitute easy to read data flow apart from the reference and error wires), should i be looking at taking a softer line on variables?

Of course it has not escaped me that there may well be a simple non-variable based answer....

Being fairly new to LV, the most reoccurring problem i have is knowing which is the best solution, when there are several alternatives to choose from. ...and yes i have forums and books and tutorials and manuals coming out of my ears...

[Wiebe@CARYA]

Passing one control to the subVI's at start and register for it's value
change event. In the main, send value (signalling), and the VI's will stop.

Use shared variables.

Use a user event.

Make a button on the sub VI front panel and poll it. Set it's value with Set
Control Value method.

Make a button on the sub VI front panel and catch it's value change event.
Set it's value with a value (signalling) in the main.

Use a global buffer (much better then a normal global).

Make the subVI poll the caller's (main vi) execution state. If it's idle,
stop the sub VI.

Use a queue.

Use an occurence.

Create a TPC/IP connection with the main as listener, and the sub VI's
connecting to it.

I'm sure there are more ways to do this. I always use user events, since my
entire architecture is build around them. Global buffers, AKA smart globals,
LV2 style globals, action engines, are the next best thing. Normal globals
are evil.

Regards,

Wiebe.

[tst]

Thank you for demonstrating the problem with the anti-globalist movement. It's not that globals aren't a potential for problems. It's just that there are cases where they are valid (most often when there's a single writer) and repeatedly telling people "DON'T USE GLOBALS!" results in people coming up with much more problematic solutions, as you've found out yourself.

In this case, the global is definitely the better approach.

Another approach I like better is using a simple LV2 style global to do this, because it allows every loop to stop the sequence. Of course, that's not always appropriate for the architecture. My simple version has two inputs (reset and stop) and a single output (stop) and is placed before the conditional terminal. Any loop setting stop to T causes it to be T for all the other loops. There are other versions which use names, so you can have groups of loops, etc. but it all depends on what you need.

Other options include notifiers, queues and dynamic events, but the global is usually the simplest.

[BlueTwo]

Thanks for the comments, Wiebe -that sums up my situation, like a child in a sweet shop which do i choose?     ...gotta learn more. Though there is a certain appeal of Henry Ford's approach to consumer choice.

tst, thanks for the input, good to read. It aligns with my perspective, -though that is something i am still evolving. I think the LV2 approach would work well for the small amount of data in my app, as well as the stop flag. Thanks for the link, always great to have them pointed out, dredging can be a bit hit and miss.

atb

Blue 

Where's the Spanish Inquisition..... ?

[tst]

My problem has always been that people say "locals/globals are evil" and then there are two bad options:

1. People reading this think "ooh, they're experts. That must mean they're right and therefore I will do something else". That something is often worse without the user even realizing it (e.g. using value property nodes or using convulted and fragile method like the Set Control Value method, all in the name of avoiding the use of the simpler tool).
2. The user says "wait a minute. That's ridiculous. The local/global is obviously the simpler solution. I guess that means those people don't know what they're talking about. I won't listen to them".

As for the inquisition, they have been retired for quite some time, and I guess I must be growing old, since the Brain has been around for a long time already without me feeling like replacing him.

[Pnt]

I agree with tst.

Hey Wiebe, what is a "global buffer " ?

[Wiebe@CARYA]

"Pnt" <x@no.email> wrote in message
news:1225570205971-802300@exchange.ni.com...
> I agree with tst.&nbsp;Hey Wiebe, what is a &quot;global buffer &quot; ?

Global buffers, AKA smart globals, LV2 style globals, action engines.

Note that my list is by no means a list of recommendations. It just
indicates that there are lots of ways to solve a problem. which is best
depends on lots of things, perhaps most important the programmers
experiance. It's much better to use a method that you understand. Also, it
will be usefull to find out yourself why globals are evil, and then look for
an alternative.