LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Darin.K

Allow Wiring to Determine Property Node Read/Write

Status: New

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.

 

ReadWritePropertyNodeBD.png

 

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.

16 Comments
Yamaeda
Proven Zealot
Good idea, alternatively property nodes should be dynamic and switch according to the wire (basically #4), with a sound signal indicating it changes. else it must be write then read.
G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
tst
Knight of NI Knight of NI
Knight of NI

I think fabric's suggestion of breaking the code if neither terminal is wired is the most reasonable, but I'm still somewhat concerned about this. In general, for things like this, I prefer safety to convenience and speed, because debugging something like a missed wire to a property node retroactively would take a lot more time than changing properties to optional or read only.

 

This could probably be alleviated by combining the various suggestions:

 

  1. The default mode would be some form of a required write (or a user setting, but I think a required write is preferable), either with a read or like Ray's original idea.
  2. Changing modes (W/R/W+R) could be done quickly using Shift+Click on the property (since Ctrl+Click is already taken. Yes, go vote for that. Go, now).
  3. An optional write mode would probably not be required if you could quickly move between modes. If you don't want to write, just change it to read only.

___________________
Try to take over the world!
Manzolli
Active Participant

Agree with tst and Darin.K. A click on the triangle to change from read to write. Should not accept connection in both sides.

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
GregSands
Active Participant

It seems that this functionality should similarly apply to Local and Global Variables, and maybe Shared Variables too.  Any reasons why not?

fabric
Active Participant

"It seems that this functionality should similarly apply to Local and Global Variables..."

 

That would be nice... If you're going to mess with people then do it once and do it properly! Smiley Very Happy

 

Might be a good opportunity to implement this idea too: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Implement-Variable-Nodes-similar-to-Property-Nodes/idi...

 

r_good
Member

Man talk about a time saver (and mouse saver).

 

I like this idea a lot. 

 

It seems that it is intuitive either pass through or go left to right (write to read, options 1 and 3) which seems to be a consensus.

 

As for the error handling.  This may be quite a stretch but tst has a great point.  Maybe let the error handler let the user know that there is no input or ouput connected as a warning so that it is possible to find downstream later.  Not sure this 100% solves the problem.

 

Best,


Adam