Text Ring Strict Type Def Update Bug for Constant

[PJM_labview]

Editing a strict type def ring does update controls or indicators instances but does not update constant instances.

This is a severe bug in my opinion, as it make using ring text constant unusable on block diagram (since for every edit you have to fix all of your constants instances. You loose the entire benefit of the typedefness [is this a word?]).

See example below that demonstrate the bug.

Download File:post-121-1163454674.zip

PJM

Edit: Apparently this may not be a bug but an expected behavior. I knew there was a reason why I though that I should never use either text or menu Ring.

[Donald]

If the controls/indicators follow the typedef, the constants should do too. I was not aware that typedefed control/indicators of a ring follow their typedef now.

One of the differences with enums is that the data range of ring is not bound to its array with strings and values... The 'allow undefined values at runtime' option is more to prevent user input. The typedef locks the user interface part of the control but not all of its data behaviour.. See my example (lv711).

I guess this is why the constants do not follow typedef changes. It is a pitty because ring values do not have to be sequential and would be nice error number constants holders e.g.

I think NI should rather unlock the interface for creating sparse enums because the behavior of enums is much more consistent. I have seen such enums in LabVIEW so it is possible (with CVI??) .

Download File:post-2015-1163495288.llb

[ned]

This doesn't solve the problem, but if you do need to force your constants to update, open the strict type definition, change the representation to some other data type (ie, U16 to I32), apply changes, and then change it back. This was mentioned in an Info-LabVIEW post a year or so ago.

[PJM_labview]

This doesn't solve the problem, but if you do need to force your constants to update, open the strict type definition, change the representation to some other data type (ie, U16 to I32), apply changes, and then change it back. This was mentioned in an Info-LabVIEW post a year or so ago.

This is a good trick.

Thanks

PJM

[Christina Rogers]

This is a good trick.

Keep in mind that you must have all your typedef instances in memory for this technique to work.

The short answer to why this is not a bug is:

• Typedefs only update on type changes.
  
• Strict typedefs update on all changes (including cosmetic modifications)
  
• Ring text is not part of the data type. Enum text is.
  
• There no such thing a strict typedef on the diagram.*
  

Now, being a usability advocate, I'm going to argue that "working as designed" doesn't mean it's right. The LabVIEW team has been struggling with how to fix this problem.

Would anyone be opposed if we changed it so that constants that are linked to strict typedefs update on all changes, the way front panel instances do?

The downside is that you have no control over what a constant from a typedef looks like. So, for example, if you create a constant from a strict typedef cluster and then resize the constant, whenever the constant updates you lose your resizing.

- Christina, LabVIEW R&D

* - The reason constants of strict typedefs are demoted to non-strict typedefs is because "strictness" generally applies only to cosmetic attributes which are meaningless on the diagram. I think the use case for rings was not fully considered, and that's part of why we're considering changing it.

[Grampa_of_Oliva_n_Eden]

...

Would anyone be opposed if we changed it so that constants that are linked to strict typedefs update on all changes, the way front panel instances do?

...

- Christina, LabVIEW R&D

...

YES! This would invalidate the half dozen threads where I explained what you just said!

Serious now:

I see no problem with that change and it would make the rings behave as many users expect. :thumbup:

Thank you,

Ben

[Donald]

I would rather see the option of creating enums where the values of the strings do not have to be sequential. Is this not why ring constants are used instead of enums?

I fear for nasty bugs in existing projects when you change the behavior of a ring constant.

Also execution speed could be inferior by adding extra features.

The string info is not part of the data-type, please leave it like that. Please note that the combo box has a similar behavior.

[Aristos Queue]

I would rather see the option of creating enums where the values of the strings do not have to be sequential. Is this not why ring constants are used instead of enums?

Within NI, I have to use rings instead of enums because rings can be localized into various languages without recompiling the diagrams (the data types don't change).

[jaegen]

...

Would anyone be opposed if we changed it so that constants that are linked to strict typedefs update on all changes, the way front panel instances do?

...

I would certainly be all for this ...

Of course, I'd love a few other things too:

1. It would be nice to somehow be able to retain formatting (or at least resizing/autosizing) of type def constants. It's really annoying when you make a simple change and suddenly the constant extends up and down off the screen. I almost never use constants for cluster type defs because of this. Could you add a block diagram to the control editor for strict type defs, and have this allow cosmetic editing of the type def's constant representation???

2. It would also be nice to have non-contiguous enum elements - but I understand this would probably be rather difficult to implement at this stage of the game.

3. Have some means of having a strict type def which is actually just an "instance" of a non-strict type def, or at least some way of keeping cosmetic edits made to a non-strict type def instance. I often have the situation where I want to put a type def on the front panel, so it has to be nice and pretty, but I'd rather have all the cases where I'm just using the type def for its data not take up so much space. Currently the only options are:

• Make the type def non-strict and simple, pretty-up the front panel instance, and have changes to the type def totally kill all of your prettying
  
• Make the type def strict and prettied-up, and use this everywhere (even though it's overkill and makes it hard to have tidy sub-VI front panels).
  
• Make the type def non-strict (or strict, but only to keep it small and simple everywhere), and don't use the type-def at all for the pretty version (Dangerous! Type def changes don't get propogated at all).
  

I just realized that perhaps XControls provide a way around this - I'll have to look into that (I'm a little concerned about XControl overhead just to achieve this though)

Jaegen

[PJM_labview]

I would rather see the option of creating enums where the values of the strings do not have to be sequential. Is this not why ring constants are used instead of enums?

I fear for nasty bugs in existing projects when you change the behavior of a ring constant.

Also execution speed could be inferior by adding extra features.

The string info is not part of the data-type, please leave it like that. Please note that the combo box has a similar behavior.

While changing the menu or text ring to embed the string info will be good for my LV usage, I can see why this could potentially create problems in other people existing code.

The reason why I was using the ring constant was to create a sparse enum, so if we had the ability to have enum with non sequential string this would cover most of the use case (if not all) I may have for using a menu/text ring constant.

PJM

[Donald]

Within NI, I have to use rings instead of enums because rings can be localized into various languages without recompiling the diagrams (the data types don't change).

That is a good reason I did't think of.

[Christina Rogers]

I fear for nasty bugs in existing projects when you change the behavior of a ring constant.

Also execution speed could be inferior by adding extra features.

The string info is not part of the data-type, please leave it like that. Please note that the combo box has a similar behavior.

Just to clarify, I'm not suggesting we would change rings in any way. The only change would be constants that are linked to strict typedefs updating at the same time that front panel instances update. That means when their time stamp is out-of-date instead of when their type is different.

So this would only affect load time, and have no effect on execution speed at all.

[Michael Aivaliotis]

The only change would be constants that are linked to strict typedefs updating at the same time that front panel instances update.

I always assumed this was the case in the past. So this means you will implement what everybody thought already happened? Sounds like a plan!

[jpdrolet]

I see a problem with that. After typedef edition, does the diagram constant keep its value (changing the displayed item string) or keep its displayed item string (changing the value)? There are circumstances where the former option is needed and others where it is the latter that is more appropriate.

[Christina Rogers]

I see a problem with that. After typedef edition, does the diagram constant keep its value (changing the displayed item string) or keep its displayed item string (changing the value)? There are circumstances where the former option is needed and others where it is the latter that is more appropriate.

That's actually a separate problem. Currently (and I'm not planning to change this), a ring constant will preserve its numeric value and an enum will preserve its name.

[EJW]

Keep in mind that you must have all your typedef instances in memory for this technique to work.

The short answer to why this is not a bug is:

• Typedefs only update on type changes.
  
• Strict typedefs update on all changes (including cosmetic modifications)
  
• Ring text is not part of the data type. Enum text is.
  
• There no such thing a strict typedef on the diagram.*
  

Now, being a usability advocate, I'm going to argue that "working as designed" doesn't mean it's right. The LabVIEW team has been struggling with how to fix this problem.

Would anyone be opposed if we changed it so that constants that are linked to strict typedefs update on all changes, the way front panel instances do?

The downside is that you have no control over what a constant from a typedef looks like. So, for example, if you create a constant from a strict typedef cluster and then resize the constant, whenever the constant updates you lose your resizing.

- Christina, LabVIEW R&D

* - The reason constants of strict typedefs are demoted to non-strict typedefs is because "strictness" generally applies only to cosmetic attributes which are meaningless on the diagram. I think the use case for rings was not fully considered, and that's part of why we're considering changing it.

Christina, if you check support reference #7122877, i had a similar issue, which was resolved with the release of 8.2

---- they had considered it a severe bug at the time and corrected it in time for 8.2 shipment.