Create a Variable selector node

[1984]

I use single process shared variables quite often and I am always amazed how much space the take from the block diagram. As they requires room I either make long VIs or play with the wires. Not good...

The current situation:

So why dont we have something similar than what we have with property nodes, but applicable to the variables we have in the project? Each variable can be set to read or write, same as the properties of a UI element.

The proposed solution:

I dont have too much experience with locals and globals, but I guess this idea could be applicable for those as well.

[AristosQueue (NI)]

> > If existing functionality is simple to implement, do you really have a problem?

> Yes I have... 826 kudos, for an a functionality simple to implement.

Merely because it is simple to implement does not mean it is a good idea.

A thousand people asking for it does not imply that it is the right thing to do. 

You are of course welcome to implement such a subVI for yourself. It does not belong in the core LabVIEW libraries, for reasons explained in that thread. If you wish to argue those reasons, please do so in that thread.

[1984]

Yes! Kudos for you! It IS an inconvenience. Look at the ideas in this forum. Most of them are not addressing  something you can not achive with LabVIEW right now. They are mostly talking about issues could be done easier.

[1984]

@AristosQueue... yes I agree. Maybe this is the worst idea ever, worth to be rejected immediately. But answering it by "hey you can do it by subVIs" is not a real answer as most of the problems here can be done by subVIs. For the record: on that forum I guess the answer made a lots of sense and the idea was not rejected by simply saying that users should create their own subVI.

My argument is: if a serial execution is not a problem with the property nodes, then why would be a problem with variables? I reserve the chance that there is something in the deep I dont understand, but my point is that if we allow users to access multiple properties in one node, then why would it be different with variables?

[AristosQueue (NI)]

I acknowledge the inconvenience. It is something worth looking at. The open questions are how much effort is it worth to address that inconvenience and, if it is worth addressing, what's the right way to do it.

In response to your argument, 1984, about serial execution:  Properties of a single object make sense to access serially -- the whole object is taking on a new state, one setting at a time. Variables on the other hand are each separate software entities. If they were parts of the same entity, there'd only be one variable (a cluster or a class most likely). Those separate variables may or may not have any connection to each other and definitely represent independent entities do not make sense to access serially. The method that updates the measurement value also updates the error, but there may or may not be a reason to wait to publish the error until after the measurement is pushed. If we had a need to combine them serially, then that would be a reason to push this redesign. Instead, the use case put forth is to solve a purely syntactic problem of names taking up too much space and an editor problem of making it easier to select multiple variables. Neither of those problems calls for a semantic change, thus this particular solution doesn't seem like a good solution to me. Does that make sense?

[PNR]

I see the point in the current situation, variables take too much space for sure! A Sub-VI is a good workaround and I actually would go for it, because if you want to change an existing variable everywhere in the project, you only have to change it in that particular VI. However for small projects (and for very big ones?) it is very tedious to create one VI for each variable (maybe for a couple it is ok, but for all? nah - There are some variables I only need in one VI. A sub-VI is somewhat overkill...). A Property-Like behavior sounds feasible, but AristosQueue clarified the issues already and I guess he is right.

Now I would love to see a BD where we can actually use shared variables and don't have to scroll until my mouse breakes.

So how about an option to change the display of shared variables to 'Short Names' or 'No Names'? That option is available for property nodes and the Call Library function (and even more functions if I'm correct).

[1984]

@AristosQueue: my analysis:

1. If the user is concerned about the parallel execution he can place multiple instances of the variable node to the BD so he practically has EXACTLY the same as what he has today. In this case the proposed solution has no benefit over the one we have now.

But...

2. in many cases the user wires up the variables serially (as it is shown on the top figure)

3. or because wiring all the error clusers is very space consuming the user just drops all the variables in a case, or a flat seq etc, and he is absolutely not interested in the execution order.

As far as I see in the case of (2) and (3) the user has a reasonable benefit in having all the variables accessed by one node, while in the case of (1) he has no disadvantage compared to what we have today.

These were my last argument about this topic.

I could suggest to make the variables collapsible with a label matching the variable name (similarly to as we can collapse cluster constants today). I just dont find this as elegant as the original idea, so I let somebody else submitting it if at all.

Good bye cruel world.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.