It is well established that local variables can introduce race conditions. We have more recently created data value references and while these can also introduce race conditions, their design specifically provides help with read/modify/write usage. It even forces all usage through this construct (border nodes on inplace element structure). What if all local access used border nodes on an inplace element structure? This would give a safe read/modify/write construct to locals (and perhaps globals).
Control references allow encapsulation of UI related code. Inheritance of control classes allows subVIs to be written to handle multiple types of controls (same subVI can be used for numeric and knob). However there are cases where this falls short. If you want to have a subVI that changes the height of a button, string or listbox, you can’t do that without the subVI having specific code for each supported control. What if you could get a data value reference to a specific control property? This means the height property from any control just turns into a data value reference to a UInt32 and a subVI wouldn’t care which control it came from.
Locals can only be accessed from the diagram of the same VI. A subVI can access the value through a property on the control reference. However, this approach requires that the panel be loaded into memory and that the access happens in the UI thread. What if you could get a data value reference to a control’s terminal? This would allow access to be passed to a subVI without UI related overhead and with safe read/modify/write semantics.
Here is a picture showing the current functionality and some mockups of what the new functionality might look like.
Would adding references to “pieces” of controls like this be useful? Would it be too confusing to have all these alternatives? Would using property nodes instead of inplace element access be preferable? Tell me what you think.
This is all interesting, but I have to admit that it does seem confusing.
The reference to a property certainly seems to have potential, and should allow writing more generic subVIs, but unfortunately it puts the burden of selecting the correct property on the user of the subVI, which is probably a big issue.
I'm not sure what I think of local or global access through the IPES. It would certainly provide better control over potential race conditions, but I don't particularly like the amount of real-estate that the IPES takes up. Forcing us to have local access only through that will annoy me in that respect. The same applies to direct access to the terminal through the IPES in subVIs, although that's less of an issue, since I don't do that from subVIs using the Value property unless its a utility subVI which is responsible for some generic task.
It will also take up a lot more space on the diagram. That can be very tight at time and I see little improvement using this. Training is the only way to keep this from happing not bigger more complicated code that can still get you right back to where you are today.