Make Control/Indicator reference types fully editable

[smmarlow]

I am a big fan of the DVR and LVOOP.  Consequently, I use lots of DVR's in my class data.  The problem is that if you configure the DVR reference to show the type control, and right-click the type control, you get a truncated shortcut menu.  The controls can also not be operated. This is especially painful if your DVR is a cluster with lots of enums that have to be edited often.  One solution is to make the DVR type a typedef and use the control editor.  But since the class data is a typedef of sorts, this method amounts to creating a typedef for your typedef, so to speak.  You can also use "customize control" from the edit menu to fire up the control editor and apply changes without saving the custom control.  But you can't check your work because you can't operate the control. Another solution is to temporarily copy the enum out of the DVR edit it, and cut and paste it back in over the original.  However, it really would be better if type controls are fully editable/operable when shown.  

Currently, type controls show a reduced shortcut menu when right-clicked, and the control cannot be operated  

It would be better if controls inside typed references could be properly edited and operated

[AristosQueue (NI)]

The controls are not operable because it is misleading in most cases -- people could get the impression that the control is somehow showing the value referenced by the refnum and/or edits the value referenced by the refnum.

[smmarlow]

@Aristos Queue.  I disagree.  There are plenty of examples in LabVIEW (typcast, datalog, unflatten from string, obtain queue, etc.) where the value of type inputs are ignored.  Do these cause confusion? It is a generally understood concept by most LabVIEW programmers that "type" controls are used for their type only, and the value is irrelevant.  The value shown in the type control of a DVR reference does not reflect the value of the memory object.  I realize a balance has to be struck between beginners and veterans, but in this case I think the added functionality and increased progamming efficiency is worth it. 

[AristosQueue (NI)]

None of the examples that you point to are on the front panel where data values are reflected at runtime.

> It is a generally understood concept by most LabVIEW

> programmers that "type" controls are used for their type only,

My experience does not match yours. I would not say this is a generally understood distinction.

[smmarlow]

DVR reference FP objects do not show the current value of the memory object at runtime. As for this not being generally understood, why then are FP controls not rendered inoperable when they are wired to type inputs?  Why are constants wired to type inputs not rendered inoperable in edit mode?  According to you, being able to change the value of these objects will mislead the programmer into believing there will be some effect.  To be consistent, you should post an idea that any object wired to a type input be disabled and locked, lest the we all become confused.

In the end, crippling editing mode for controls contained within a typed reference really only adversely affects enums.  The truncated edit menu does allow the represenation to be changed.  But it does not allow the items to be edited.  Clearly they wanted the user to be able to at least change the type, otherwise they would not have allowed the representation to be changed.  But for an enum, the type is also dependent on the item list. 

[smmarlow]

@ Aristos I should also note that I do not need to operate enums in the ref control as long as I can edit the item list.

[Darren]

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