[bug] radix change in strict type def does not trigger a change

[Darin.K]

Just noticed that if I change the radix of a display in a strict type def it does not allow me to Apply Changes to update the controls (system numerics).  I have to put in a "real" change like toggling between strict and normal to get the option.

Perhaps the Apply Changes option should always be available, any harm in applying a change with no changes?  This is probably not the only hole in the system.

[mikeporter]

Sorry to have to disagree with you about this but I don't see how what you described is a bug. Think about it this way, the whole point of the radix display is to allow the operator to be able to change it at run time. If you can change something then it is obviously not part of the type definition.

Or to put it another way, how is this case fundamentally different from that of a strict typedef ring control. You change the strings in the ring type definition and the existing instances of the ring don't show the change. Why? Because the strings are not part of the definition. How could they be? Having strings that can be dynamically changed as a VI runs is the whole point of having a ring control.

Mike...

[Darin.K]

You can not change the radix of a strict type def outside of the type def itself. The point of the strictness is to have a uniform appearance (not just type), and the radix is certainly part of the appearance. Certainly you do not think the width is part of the type, yet changing that triggers a change in the strict type def which must be propagated. And if you change the strings in a strict type def ring the changes most certainly propagate to the instances.

[mikeporter]

If what you say about strict typedef rings is true, that is a recent change - plus it effectively turns the ring into an enumeration, but without all the benefits of an enumeration. It also means that creating a strict type ring control is an exercise in futility because they can no longer do the one thing ring controls are for: displaying a dynamically generated list of selections.

(Personally, I can't say definitely because I don't use strict typedefs that often as I prefer the System controls for GUIs.)

Still I disagree about the radix, the radix control is not about the appearance of the number, it's about how the operator chooses to interpret the number. Radix, like the unit display, is there for the convenience of the operator.

Mike...

[Darin.K]

Just to be clear, I am referrring to controls, not constants.  Strict TD rings are the closest thing we have to sparse enums so to anyone who interfaces with external code a lot they are very useful.  This is off-topic. 

And so I can understand your point let me state how I understand it:

You say there is no bug here,so the expected behavior is that the operator should not be able to change the radix in a strict TD control (current behavior) and changing the radix in the strict TD itself should not be considered a change (current behavior).

I disagree, if I want subVIs to have uniform appearance it is useful to define a pointer type let's say and I would like to guarantee that it is displayed in hex in all of my subVIs.  This is a simple way to have uniformity in my API.  Strict TDs are not perfect, but very good here.  If I want the operator to be able to change the radix I will make it a TD and not strict.