New type of enum

[CarstenPXI]

To de-couple front panel from internal program representation, we always show Caption instead of Label. This also eases internationalization.

We need a similar mechanism for enums where we have a front panel "Caption" associated with each element in the enum. I recognize this requires three layers for each element: its numerical value, its name which shows up in the case selector, and its Alias (caption) which is shown on the front panel. Thus we get readable code for enums that also can be internationalized.

Carsten Thomsen

[AristosQueue (NI)]

This is an idea that the community definitely needs to chime in on.

The "problem of enums" has been presented in many LV venues over the years. I have heard of a multiple attempts -- both within NI and without -- to describe all the bits and pieces that have to work together to make this work, but all of them have had some serious usability problems. The idea you present here is a good summary of what needs to happen, but the devil is in the details for this one.

The key problem appears to me to be that LV does not require a typedef for any type, and therefore, any diagram information has to propagate as part of the type, and that means localization would require a recompile, which is a showstopper. What would be the community response to a control that could *only* be dropped from the palettes into a typedef control, that was broken if ever separated from its typedef?

Another question: Which one shows up in the case structure -- localized or unlocalized? If it is unlocalized, then it may not help readability of the diagram. If it is localized, then the probe of the wire won't show the same values as the case structure labels. If you show both, the text of the case structure gets pretty long, but maybe that's workable.

I bet there are other issues. Post away, folks!

[tst]

Since most people would typedef such enums, I don't see a basic problem with forcing them to use typedefs (maybe they could just have a typedef created automatically as they're dropped and have all the options of making them not-a-typedef disabled).

As for the other question, I would say that showing the unlocalized string is usually reasonable, as the localized one is generally for the user, but this could be an environment option.

All that said, this can't be disconnected from a better UI behavior for enums. Today, we have the system enum which looks like a regular drop down, but the modern enum still isn't a nice UI object and can't be customized nicely.

[Albert.Geven]

Hi

Enums, especially non contiguous enums should also be possible!

Localisation is a good idea. The non-localised version is in most cases readable for the group that wrote the program, and if needed you could select a localised version in the project but for me it is ok to have the non localised version on the block diagram.

An obligation to have only support typedefs is ok with me. We already want an option that new types are by default saved as typedef.

So to conclude, I like typedef enums that support localisation.

[Mark_Yedinak]

I agree with Albert. I would place the ability to have non-contiguous values before the localization. It would be very useful to define ENUMs that actually represent the data (think of a BAUD rate for example) then to require the use of lookup tables to convert. To me this is much more useful than localization. However, I can see the value of both.

[tst]

> non contiguous enums should also be possible!

The idea for this already exists - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-sparse-enums-to-LabVIEW/idi-p/925224

[johnsold]

I like this idea.  Aside from the localization issue (which is important for many people), there are times when nice, descriptive language on the front panel would be useful, but a shorter version is entirely appropriate on the BD.

As tst pointed out, the typical use would involve a typedef.  Perhaps this could be put on palette as a typedef, in the same manner as the Space constant is a VI.  The only way to customize it would be through the typedef custom control window.

If someone disconnects one of these from the typedef, it defaults to a standard enum without the caption.  This should be accompanied by a warning dialog, if feasible, and clear help documentation.

Lynn

[GregSands]

Is it sufficient to restrict the localized/caption display to the FP, but always use the internal names on the BD?  That would presumably remove the need for it to be a typedef.

[AristosQueue (NI)]

It would ameliorate the need to be a typedef, but not fix it. You would then have one source control able to localize, but as soon as you did "create indicator" somewhere downstream, you would get a control that was not localized.

[CarstenPXI]

I think I may have gotten the discussion sidetracked a bit by using localization as one example benefit of this feature.  Probably even more important is the importance of totally de-coupling front panel text from the program internals.  This permits rigorous, structured internal naming conventions without the user being encumbered with them.  And it gives us meaningful identification of case structures derived from the control.

So basically I think Greg S describes it very concisely, and the TypeDef requirement I don't even see as a compromise, we use them anyway for any control that has any type of complexity.

Carsten Thomsen

[sth]

I think decoupling the BD term from the FP display is the primary feature.  Localization ability is just a good consequence of this.  The developer can think in names without vowels or spaces as usual but have a good FP UI name.  I am with GregS on this one.