02-26-2021 02:38 PM - edited 02-26-2021 02:39 PM
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.
These are the only differences. Will they affect the running of the ctl's? If not I will get rid of one of them.
Solved! Go to Solution.
02-26-2021 02:55 PM
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.
02-26-2021 02:58 PM
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!
02-26-2021 10:11 PM
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!
02-27-2021 07:16 AM - edited 02-27-2021 07:30 AM
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
02-27-2021 11:49 AM
@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?
02-27-2021 04:35 PM
@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.
02-28-2021 12:59 AM
@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?
03-01-2021 01:10 PM
@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.
03-01-2021 03:47 PM