Does difference in Ring affect vi operation?

[colorimeter]

Based on the differences listed below, are there any differences in the output or execution of two ctl files? The files have the same name and appear in two different subdirectories of a set of existing LabVIEW 2017 code. 

1. I used Tools > Compare > Compare two vi's on the two ctl files. The difference occurs in a Ring on the Front Panel, where the object type is enum and the difference type is numeric representation. The detailled difference between the first and second ctl is: Changed from "'SameNameTwoCtls': unsigned word {16-bit integer (0 to 65535)]" to "'SameNameTwoCtls': unsigned word {16-bit integer (0 to 65535)] enum {A, B, C, D}". However there is a pull-down menu of A, B, C, D on both ctl's.
2. When I right click on the Ring > Edit Items, the first ctl shows a Data Entry tab, while the second doesn't. For the first clt, the Edit Items tab has "Allowed undefined values at run time" with an unchecked box, while the second ctl has the same info but it's greyed out.

These are the only differences. Will they affect the running of the ctl's? If not I will get rid of one of them.

[paul_cardinale · Accepted solution]

One is a ring, the other is an enum.  For a ring, the strings are changeable at run time (which means they can’t show up as frame names when a string is wired to a case structure.  For an enum the strings are part of the type and can’t be edited at run time; but they do show up as frame names in case structures.

[colorimeter]

OK, sounds like it was an "on purpose" difference so I need the two different copies of the ctl. I am going to rename them to tell them apart, though!

[billko]

Hopefully, the ring is an orphaned control not used anywhere.  If it isn't, then be prepared for maintainability headaches, as it seems they were both meant to be the same thing!

[JÞB]

From your description we can't be sure if you are actually using Rings or Enums. Paul pointed out the difference.

From your point 1 it seams that they are both Enums. But regardless, if they were of different classes, that would have been obvious in the compare vi output. Both types use the same items editor.

So we need to inspect the reason that the items editor shows for one control and not the other.

Normally I would pretend to consult my super 8-Ball but, I'm going to impress y'all with my magnificent intellect. 😉

The control that doesn't have an items editor right click menu enabled is a "Type-def" the other has been disconnected from type-def.

Both controls are presumed to be Enums.  So, Strings and values properties are read only at runtime.   The only difference is where you can edit the strings and values. For the type-def you edit them in the control editor.   Given identical strings and values, runtime behavior could not be affected by an Enum type being a defined type

[billko]

---

@JÞB wrote:

From your description we can't be sure if you are actually using Rings or Enums. Paul pointed out the difference.

From your point 1 it seams that they are both Enums. But regardless, if they were of different classes, that would have been obvious in the compare vi output. Both types use the same items editor.

So we need to inspect the reason that the items editor shows for one control and not the other.

Normally I would pretend to consult my super 8-Ball but, I'm going to impress y'all with my magnificent intellect. 😉

The control that doesn't have an items editor right click menu enabled is a "Type-def" the other has been disconnected from type-def.

Both controls are presumed to be Enums.  So, Strings and values properties are read only at runtime.   The only difference is where you can edit the strings and values. For the type-def you edit them in the control editor.   Given identical strings and values, runtime behavior could not be affected by an Enum type being a defined type

---

It's only during development when it becomes a headache.  What if there are other disconnected typedefs floating around when you need to update it?

[JÞB]

---

@billko wrote:

---

@JÞB wrote:

From your description we can't be sure if you are actually using Rings or Enums. Paul pointed out the difference.

From your point 1 it seams that they are both Enums. But regardless, if they were of different classes, that would have been obvious in the compare vi output. Both types use the same items editor.

So we need to inspect the reason that the items editor shows for one control and not the other.

Normally I would pretend to consult my super 8-Ball but, I'm going to impress y'all with my magnificent intellect. 😉

The control that doesn't have an items editor right click menu enabled is a "Type-def" the other has been disconnected from type-def.

Both controls are presumed to be Enums.  So, Strings and values properties are read only at runtime.   The only difference is where you can edit the strings and values. For the type-def you edit them in the control editor.   Given identical strings and values, runtime behavior could not be affected by an Enum type being a defined type

---

It's only during development when it becomes a headache.  What if there are other disconnected typedefs floating around when you need to update it?

---

Don't do that!  It can introduce unexpected behavior that is not easy to debug.

[billko]

---

@JÞB wrote:

---

@billko wrote:

---

@JÞB wrote:

From your description we can't be sure if you are actually using Rings or Enums. Paul pointed out the difference.

From your point 1 it seams that they are both Enums. But regardless, if they were of different classes, that would have been obvious in the compare vi output. Both types use the same items editor.

So we need to inspect the reason that the items editor shows for one control and not the other.

Normally I would pretend to consult my super 8-Ball but, I'm going to impress y'all with my magnificent intellect. 😉

The control that doesn't have an items editor right click menu enabled is a "Type-def" the other has been disconnected from type-def.

Both controls are presumed to be Enums.  So, Strings and values properties are read only at runtime.   The only difference is where you can edit the strings and values. For the type-def you edit them in the control editor.   Given identical strings and values, runtime behavior could not be affected by an Enum type being a defined type

---

It's only during development when it becomes a headache.  What if there are other disconnected typedefs floating around when you need to update it?

---

Don't do that!  It can introduce unexpected behavior that is not easy to debug.

---

Yeah, that was my point.  If there's one disconnected, how many more haven't you found that are just waiting to bite you in the behind?

[colorimeter]

@JÞB, by "Don't do that!" do you mean I can't do the following?

1) In Windows, copy the first version of SameName.ctl in SomeDirectory1 to NewName1.ctl, and copy the second version of SameName.ctl in SomeDirectory2 to NewName2.ctl. Zip the two original versions of SameName.ctl. 

2) Open MyProj1.lvproj which included the first version of SameName.ctl, open its caller vi's, and when they complain point them to NewName1.ctl. Open MyProj2.lvproj which included the second version of SameName.ctl, open its caller vi's, and when they complain point them at NewName2.ctl. 

[JÞB]

You can do that. Its painful and error prone. 😖 I don't RECOMMEND doing that