Create a control from a non-reference

[Andi_S]

Remark: This example is using the numerical-double-data-type but it is valid for all other data-types, too. I'm using LabView 2011SP1 (german)

Creating a reference from a numerical-control is not new and very easy to do via the context menu. But I'm missing a similar function to create a double-control from a double-reference / double-reference-control.

This would be very helpful especially when there is a VI that requires a reference to a special data type as input and you need to create a control of exactly this datatype.

As already suggested in an other idea here in this board it would also be helpful to have a context menu entry that allows to create a reference control from a numerical control without make the detour with a reference in the block diagram.

[tst]

This already exists. Right click the reference control and check the Show Control option. This will now show the control the reference is using and you can Ctrl+Drag it out of the reference. If the reference is strictly typed, you will get the exact data type you want.

You can also drag a control into the reference to change its type, so that takes care of the red arrow on the left side of your FP.

[Andi_S]

Yes, it exists. But it needs a lot of clicks. Then it does not work if you have a password protected VI with a reference input and I just tried it with a cluster. Look what what happens:

[tst]

That's why I mentioned the strict typing. If the reference isn't strict, then you can't get the exact cluster out of it because it simply isn't there. When you created the reference control LV didn't put the actual cluster into it. If you want to keep the type, then create the control by dragging the actual cluster into a control reference and then make it strict.

As for the number of clicks, I find it perfectly reasonable for something like this which I hardly ever do. I agree that it's not necessarily visible, but you can't make everything visible and I find its location reasonable relative to the actual importance I assign to it.

[Andi_S]

Ok - understood. So my next suggestion is to create strict references by default and not only by dragging.

Nevertheless, my original problem / idea remains:

There is a SubVI (e.g. a driver) that comes from an external suplier and maybe it is even password protected. This VI has an reference input to a datatype that I do not know. I would like to right-click to this input and get the additional posibility to create a control of exactly this data type (int, string, array, cluster ... what ever).

You're right, not everything must be visibly but the context menu of LabView has a high potential for optimization and my suggestion is just one additional entry that is only visible for reference data types.

[Andi_S]

Ok, here an example with a SubVI having two reference inputs. Both are created from the same cluster typedef but the one over the constant (like described in my first example) and one like you suggested by dragging the typedef to the reference control. Here is the result:

The VI is executable, there are no red circles for implicit type cast - with other words it is not possible to see that one reference is strict and the other one is not. The only difference is the visible in the context menue: For the normal one the the entry "Add datatype" is disabled.

=> A asterisk or something else in the icon that indicates that the reference is strict would be great.

I selected the option "show control". For the normal reference a emty cluster is shown but the VI is still executable. Looks somehow strange for me.

Now I moved the element from the normal reference out (getting a normal control). Then I directly moved it back to the referenced. The frontpanel looks identical to the step before but the VI is broken now.

Here in this picture I created a property node to the value property of the element the strict reference points to. To remember: The cluster datatype itself is a strict type def. Creating now an indicator ("Value") from the property node does not lead to the expected original type that is linked to the tye def.

Making the same with the normal reference leads to the same result.

I have no idea if this behaviour is a bug or a feature or if there are historical reasons but for me it's just annoying.

[AristosQueue (NI)]

Strict references are generally not what people want by default because they tie the UI design into the refnum. Most of the time that leads to an undesirable coupling between the look/feel of the control and the actual data presented by the control that is being manipulated. Or even just code that updates the position/layout of the control itself really doesn't care if you've got a text box or a horizontal slider. That's the reason that the control references do not default to being strict references. It's a feature you have to consciously opt into.

[Andi_S]

yes - but we were talking about strict references and not strict type defs and as I have learnd here I have to use strict references to have the chance to "reconstruct" the datatype that was used to create the reference.

How about my last sample (with the property node): Is this also what the people want?

[tst]

> ...How about my last sample (with the property node): Is this also what the people want?

I would suggest that's probably a bug, or at least unexpected functionality (I would vote for bug because this also affects an implicitly linked property node) and people have noted in the past, although I don't see a response from NI in those threads - http://forums.ni.com/t5/LabVIEW/typedef-coersion/m-p/707888/highlight/true#M324211 .

In practice it hasn't bothered simply because I don't do this ("Doctor, it hurts when I do this", "Well, don't do that").

I would agree with AQ that at least in my case I hardly ever take the strict data type into account, because that's usually only useful for the value and I try to avoid getting or setting the value with property nodes (particularly in other VIs) because that's a gateway to code that's hard to understand and race conditions which are hard to find and debug.

[AristosQueue (NI)]

> but we were talking about strict references and not strict type defs

So was I. 🙂