LabVIEW
Strict typedefs changes value throughout project
Solved!
The condition that triggers this window is that the selected enum label doesn’t exist anymore as far as a string compare between the existing items and the selected item would determine.
All the instances where such an item is selected retain the old selection but are grayed out and broken. Even if you dismiss the dialog, which I sometimes do in my zealous attempts to get at a specific different window, this condition remains and you can go to the broken VIs from the error window to find them.
I would think that you need to have the relevant VIs loaded at least inside a project at the time of the enum edit to make this work alright. In my experience the VI does not have to be open as long as it is present in the project in which the enum is edited too. It’s important to always work within a project to let LabVIEW have an overview on what you are working!
And the next LabVIEW release will be even more reliable in finding “This VIs callers” when selected in the popup menu inside a project.
@s.h._tech wrote:
When changing 'enums' the compare window appears (sometimes).
Adding controls to a cluster, even another enum may leave the value intact or just resets it to the default setting.
I have the same experience when changing the .ctl of classes. Sometimes when I add / remove elements the references of existing controls change (when 'Unbundle_by_name' is used). This is not a problem as long as the randomly assigned value has not the same datatype and I can follow the broken connection.
My usual course of action is to search for the element and manually check the values of the constant. This often proved tedious since some parts of the code was written weeks ago and I have to familiarizes myself with already finished parts of the project
I've never had this window (knowingly) fail me by not appearing when something changed. I know that enum (and indeed any) values inside a cluster can revert to their default values without notice, when changing something inside the cluster, if you use a typedef'd constant directly on your block diagram. Best practices dictate that you always bundle changing values into your cluster to avoid this. In other words, don't drop a typedef'd cluster onto your block diagram and change the values inside, or otherwise depend on the values inside a typedef'd cluster constant. Always explicitly determine the values to be used.
