Numeric strict type definition with radix visible, radix is not visible by default on Block Diagram for the type def constant

[cdhibd01]

If you create a strict type def of a numeric control and select radix visible and say change radix to Hex.  When you drop the control on a front panel the radix is visible and the number is in Hexidecimal format.  However if you drop this control onto a block diagram as a constant, the numeric constant defaults back to Decimal format and you must then right-click toi show Radix and change to Hexidecimal format.

If you strictly define the control to be in Hex format, the 'strict' type should be applied for the constant as well as for the controls and indicators.  Cuurnetly it will default as Hex format for control and indicator, but not as a constant on the Block Diagram.

Using LabVIEW 2014

[AristosQueue (NI)]

Hm... I see your argument, but it would make that option behave differently than every other strict typedef option. Making a typedef strict only impacts its front panel appearance, not the diag appearance. It's been useful to have a clear divide there to say "it affects this but not that." I don't think, for example, that setting the width of the numeric should impact the block diagram width. And there's the question of whether toggling the radix visibility would toggle it on all the block diagrams, the way it does on the panel.

I'm not saying this is a bad idea. I am saying it would need some consideration.

Any other users have feedback?

[GregSands]

I agree this idea would be helpful.  If the radix is set to other than the default, then it's likely to be important whether used in a control or a constant - and that's probably the case for a non-strict typedef as well.  Maybe add string representation as another similar property.

The problem I see is that you have no block diagram editor for a control, so it's not clear exactly which properties might be carried across into a constant.  I don't think there should be a BD constant editor - that's way too much work for too small an issue.  But it wouldn't be a huge problem if a few appropriate properties were documented as applying also to BD constants.  I'd agree size is not one of those, but others may think differently.

So my kudos is for this idea, but not for any radical reworking of customizing controls.

[AristosQueue (NI)]

GregS: What are your thoughts about the toggling behavior?

[GregSands]

To me it would make most sense to mirror the FP behaviour for those few properties which would be carried over to the BD.  LabVIEW is always easiest to work with when it is consistent!  So radix visibility should behave the same way on both.

[AristosQueue (NI)]

> LabVIEW is always easiest to work with when it is consistent!

By that logic, size should carry over. 😞

[GregSands]

>> LabVIEW is always easiest to work with when it is consistent!

> By that logic, size should carry over. 😞

I did say "for those few properties carried over", and size is not one of those 🙂

Another option is that BD constants should simply be drawn as the FP control.  OK, so that's a really bad idea!

Well, the original idea still gets my kudos, but I can see there are many problems with the implementation of that.

[GregSands]

>> LabVIEW is always easiest to work with when it is consistent!

> By that logic, size should carry over. 😞

I did say "for those few properties carried over", and size is not one of those 🙂

Another option is that BD constants should simply be drawn as the FP control.  OK, so that's a really bad idea!

Well, the original idea still gets my kudos, but I can see there are many problems with the implementation of that.