LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Does difference in Ring affect vi operation?

Solved!
Go to solution

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.

 

 

 

0 Kudos
Message 1 of 14
(277 Views)
Solution
Accepted by topic author colorimeter

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.

"If you weren't supposed to push it, it wouldn't be a button."
Message 2 of 14
(268 Views)

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!

0 Kudos
Message 3 of 14
(263 Views)

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!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 4 of 14
(213 Views)

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


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 14
(178 Views)

@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?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 14
(163 Views)

@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.


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 14
(156 Views)

@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?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 14
(144 Views)

@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. 

0 Kudos
Message 9 of 14
(106 Views)
You can do that. Its painful and error prone. 😖 I don't RECOMMEND doing that

"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 14
(94 Views)