LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Allow Wiring to Determine Property Node Read/Write

This recent idea reminded me of something I have wanted for quite some time now:  the ability to determine if a property is read or write based on wiring, not some half-buried option in the right-click menu.




The basic idea is simple:  all properties have two terminals, one for writing and one for reading (except read-only of course).  No right-clicking, just wire up the direction you want.


The bottom case is a bit interesting.  I see a few possibilities:

1.  Passthrough (cosmetically saves branching, crossing, etc.) Same behaviour regardless of errors.

2.  Read then write : returns previous value.  What happens if there is an error?  Passthrough, old value?

3. Write then read: almost always passthrough.  In case of error would it return old (ie. actual value) or passthrough?

4. Do not allow this.


I would expect it to perform the write and then the read (3) or passthrough (1).  What is more important to me is the actual value and not the intended value.  Mentally I just see data flowing into then out of the PN when both are wired. 


Bottom line:  I see no reason not to permit the wiring to determine read or write of a property.


If there is a cop-out lack of consensus and simultaneous connections are not allowed, I would at least ask for a keyboard modifier (say shift) such that I can shift-drag to expand the PN and get the same property repeated instead of going down the list.  Then I could at least do the write+read with a lot less mouse movement.

Active Participant

Excellent idea!


Regarding the R/W case, I agree that (1) or (3) are the most intuitive... Passthrough seems the most obvious, but I'd settle for either. I can see good use cases for (2) but it seems to conflict with my mental dataflow expectations.


And for cosmetic refinement: If a particular terminal is not connected, it would be nice if the corresponding black arrow were dimmed or "un-filled"...

Chris Virgona
Knight of NI

I agree! This is much more natural! In addition, I would really like if the terminals (e.g. visible when hovering) are at the edge of the node and not in the center. The current layout makes it so easy for wires to get buried when moving the node and it is hard to tell where they go.


I don't like option 2.

Active Participant

Case 2 is probably more useful in practice, as you that way is able to both get the former value and set the new value in one go. Even though it goes somewhat against the common left-to-right dataflow it's the same as with feedback nodes.


If case 2 is not an option I think it's better to disallow wiring both terminals as cases 1 and 3 doesn't bring anything to the table that's not already possible by just branching the input wire. I feel cases 1 and 3 would actually promote bad programming practice as it tastes a bit like wiring under the node.




CLA, CTA, CLED & LabVIEW Champion

Good idea!

I am against option2: it is highly counterintuitive (though I understand its usefulness).

Knight of NI Knight of NI
Knight of NI

One problem with this is what you mentioned in the other idea - the code won't break if don't wire anything into the input. I happen to like that the code breaks and I think I would prefer it to this. I don't object to a write terminal being pass-through, but I think I would still want it to break. Maybe a shortcut for more quickly changing from read to write and back would be useful.

Try to take over the world!
Trusted Enthusiast

> One problem with this is what you mentioned in the other idea - the code won't break if don't wire anything into the input. I happen to like that the code breaks and I think I would prefer it to this.


One possibility is to actually use the triangle glyph for something useful.  I would suggest the PN drops with a hollow triangle for the input which would mean optional.  Click to make it a filled triangled and therefore required, breaking your code if you like that sort of thing.  Some nodes also use shading to reflect inputs which are optional, that could work as well, and just for good measure you could make the text bold as well.


With this change I think the PN is drop and play in almost all cases, and for the break until I wire something case, the shortcut is much more intuitive and easy to reach.

Active Participant
I would be happy for my code to break if *neither* terminal is connected. If I wire any one of them, then the IDE can assume I'm good to run again...
Chris Virgona
Knight of NI

I'm with tst on the code breaking if nothing is wired (or if nothing is wired on the write?)  Simply because if you intended to wire a value to the write, got distracted and only wired the read, then debugging this could be a bit of a struggle.  You'd always get the previous value.  Not the end of the world (unless coded on Dec 21, 2012), but it could be annoying to debug.  If it requires additional steps to overcome this, then we are back to square one, and my original idea prevails.


In any case, I do like this one and gave it Kudos.  Plus I would prefer option 3 with passthrough.

Active Participant

Great idea. But I don't see any reason why we should need anything except case 1. Everything else seems clunky and counterintuitive.


"Without data you're just another person with an opinion." - W. Edwards Deming
Proven Zealot

I like the idea. My preference is for case (3), although...


> In case of error would it return old (ie. actual value) or passthrough?


I would suggest it would return the default value for the data type, i.e., the same behavior you get today when you read a property and there's an error. Reverting to the default value often (depending upon the specific property) makes it simple to check downstream just the value on the output wire without having to separately test the value of the error cluster.