Wrong linking of cluster elements after deleting elements from typeDef

[Bob_Schor]

AE/FGV = Action Engine/Functional Global Variable.

I'm curious about your statement that you do a search for the TypeDef, it lists 20 VIs, but "there are more parent VIs".  When you do a Find All Instances, I believe that it looks through all the instances in memory.  I have a number of programs where I have "flexible clusters" that change from Version to Version (often adding a new "feature" means modifying one or more clusters).  Several of my clusters have a semi-fixed structure and order, so elements tend to be added (or removed) in random locations.

When this happens, I bring all of my VIs into memory, then do a Find All Instances.  It does seem to find them, and it is usually easy to spot the problem spaces.  The following have been my (limited, unscientific) observations:

• Changing the name of a single element is not a problem (do a Save All to "apply" the change)
• Changing multiple names might lead to a mixup, so I look carefully at these cases.
• Adding a single element usually works.  Similarly, adding a group of contiguous elements usually works.
• Deleting elements, particularly "interior" ones, can lead to shifts and mixups.  Check carefully.

Another LabVIEW element that has a similar "Check after modifying" situation is the Enum, particularly if used as the name of a State or Action (for State Machine or Action Engine).  These tend to become Case Selectors, and I've frequently seen "interior Cases" get shifted by one when a new State was added (or removed) from the middle of the Enum.  However, if I rigorously apply what some might call the Reagan Principle ("Trust, but Verify"), I can usually find and correct the self-induced "bugs" before they appear at Run Time.

Bob Schor

[Raeff]

Hi Bob,

Thanks for your help.

What I meant is: there are 20 Instances of this typedef but there is e.g. a VI called getClusterTypeDef.vi which is used for access of this Cluster. Therefore, each (parent) VI that contains this getClusterTypeDef.vi needs to be checked as the actual cluster is then in the parent VI an can be accessed via bundle/unbundle by name. like in the pic:

Thank you alot for your list of advice on when to be more careful with the modifications. I appreciate it a lot!

Also thanks for the hint with the Enum, we will check if that caused any unknown problems in our code as we have some state machines in use.

We will then carefully apply the Reagan Principle.

Best,

Raeff

[Alexander_Sobolev]

If you delete element from cluster, Labview tries to find another element with the same name (further in cluster, at the same hierarchy level of the same type).

To be safe, you can first unbundle "subcluster 3", then all of its elements. If it does not find element, named "subcluster 3" in supercluster, then it gives error if you delete it.

[WNM]

Since I still sometimes work with older versions of LabVIEW that were even worse about this than the current versions, I have developed some habits that generally help me to be successful in doing what you are trying to do. 

First of all, make sure that all VIs that use the cluster/typdef are in memory before you start changing things.

Second, do whatever you are doing 1 step at a time. Make a change to your cluster / typdef and then "apply the change" and let it percolate through all the VIs and manually fix any problems that occur as soon as they occur.

Third, when making changes that involve pieces that use identically-named parts, start out by changing the names (again, one at a time) to unique names that cannot be confused with any other elements in the structure.

Fourth, before you go deleting chunks of a cluster, search on its now-unique name and find all instances where it is referenced / used / wired and delete those uses before deleting the the chunk from the cluster.

Finally, I don't know if this last step is strictly necessary, but it makes the foregoing 4th point easier to accomplish. Whenever I use a bundle or unbundle operation, I always do it on a cluster-by-cluster basis so that if there are embedded clusters within clusters and I want to get to an internal bit, I use multiple unbundle functions rather than a single all-inclusive one (with the full names either hidden or shown) .  This is definitely more tedious with bundle operations but it certainly seem does help to keep the bits sorted out and make it easy to find where they are used.

[midam]

Having the same issue and just had a reply from a local NI tech support that there is no easy solution for this with LabVIEW2016.

I thought this thread deserves to be bumped up so that LabVIEW developers in any level can be aware of this issue until solution arrives.

[alanturing]

Dear all,

first of all thank you very much Raeff for having pointed out this problem so well.

Let me say that I run a fairly large project in which I do make use of very large and nested clusters, which I have made as typedefs PRECISELY to exploit automatic propagation of changes all around the code.

I totally agree with the comment that LabView, trying to be too smart, it just creates much extra work (and time loss) for me.

Let me say that I find the answers like "just check all the dependencies yourself" and "design better the code in the first place" quite insulting of the person who raised the question and not worthy of the reputation of a "Knight of NI".

Also, the comment about changing variable names is nonsense for me. A language that places constraints on the words that can be used (name of the variables), is not a language. It is an oppression.

Finally, the OOP comment. Of course, one encapsulate variables for the library users, but at a deep-enough level, private methods need to access the cluster.

I find this compile-time name resolution a very convenient feature of LabView. Propagating (correctly) the changes or detecting (correctly) mismatches it is a key feature for me. I think the way changes are propagated now is really nonsensical.

In particular, why when an item from a typedef nested cluster is removed, LV should never try to "fix" the bundle or unbundle blocks referring to the removed item but just leave the accessing VI in a broken state. In this way, one can easily see where the item was really used. Note that VI dependencies are not useful when a large typedef is used by a large number of VIs.

I can imagine that when you move leafs from one place to another in the typedef cluster, it is convenient that LabView corrects automatically the references in the using VI. However, as this mechanism is clearly not 100% reliable, it would be better to be OPTIONAL.

In the end, I think there should be a config which allows typedef to become "stupid" again (avoid fix dependencies) if the programmers so want. I think that would also save me time, currently, it takes 2 min to do an update of one of my core structures.

Sincerely,

[sbritzelm]

Totally agree with you ! In my opinion this behavior is unacceptable. It's just another example for a unnecessary complicated implementation in this overaged software. That's why they put NXG on the market with a brand new concept ... we will see - the change is overdue.

[Chickentree]

---

@alanturing wrote:

Let me say that I find the answers like "just check all the dependencies yourself" and "design better the code in the first place" quite insulting of the person who raised the question and not worthy of the reputation of a "Knight of NI".

Also, the comment about changing variable names is nonsense for me. A language that places constraints on the words that can be used (name of the variables), is not a language. It is an oppression.

Finally, the OOP comment. Of course, one encapsulate variables for the library users, but at a deep-enough level, private methods need to access the cluster.

---

Exactly. I was taken aback reading the initial part of this thread. I am also suffering from this problem.

[RavensFan]

What if you attack the problem this way?

Before deleting the items, replace the items you want to delete with a control of a different type.  So replace the numerics with booleans.  This should break the wires in all the places in the code that have numeric controls, indicators, or constants wired to them.  Then go search for those errors and weed them out.  Once you've hit all the spots in the VI hierarchy, then proceed to delete those controls from the typedef.