Deleting Control from Type Definition casuses many misreferences and program errors in Block Diagram

[dbaechtel]

How would Classes and Mutation History help with this issue?

[Ben]

Deleting an element for a type def has often been interesting over the years.

Some recomendations;

1) Avoid deleting elements from a type def if you can.

2) If you are going to delete, then first edit the type def to change the data type of what you are about to delete, to an incompatable data type to break your code ON PURPOSE. Then go through the code an remove all rfs to that element BEFORE you delte it.

3) Use a "Tree.vi" to ensure all users of the type def are in memory when the edit occurs.

4) (contradicting the above) Edit your type with all users of that type CLOSED (this came from NI support the last time I reported bugs with edits).

I think there are two bottom lines I would like to share.

A) THe cluster/bundle/unblundle code is very impresive and it has boggled my mind more than once how well LV handles this tedious work.

B) LV is not fool-proof in this area and users should be carefully when editing types defs.

And to make sure you know that I do understand the seriousness of this bug...

1) First time it hit me (LV 7.0)

 The wrong filed was selected after an edit, no broken code but new symptom that the more often an app was run, the slower it would start-up! ("Start time was "0" so loading history from the bgining of time).

2) Makde small change to code an customer calls and reads me the roit act acusing me of not testing "My tach vlaues are showing up in my horse poweer!". Wrong value was being bundled.

Now even if NI fixes this flavor of the bug, thses issues sneak in with new version of LV and we never know when we will be the first to see this version of teh bug. So be aware that this bug can happen and be ready to revert to a backup after editing a type def.

Just sharing my experience, good news or not,

Ben

[dbaechtel]

I appreciate your advice on this issue very much.

I wish that when these types of issues are identified, that NI change the implementation so that unintended side effects like this are eliminated. I assume that doing this is part of their process.

[RavensFan]

One other way to avoid the problem is to always work with the cluster and get the array of references to all the controls in the cluster.  Then use that to search for your control of interest by name.  Then once you find that you can cast to a more specific class on that reference and pass that to a property node explicity and work with the property you want.

The two main disadvantages,

1.  A lot more code you need to write.

2.  It still has the flaw that if you change the name of the control in the cluster, you'll have to go around and change the string constant you used to search for that specific name.

Advantages,

1.  I won't break the other property nodes.

2.  If you do forget to change the string constant, you should be able to catch the error at run-time.

[dbaechtel]

Can you show an example of what you have proposed?

[RavensFan · Accepted solution]

Something like this.

 

[dbaechtel]

---

@Ravens Fan wrote:

Something like this.

 

---

Perhaps 3/4 of your example could be turned into a subVI with inputs: reference to Cluster and name of desired control; and outputs specific reference to desired control and control type. That could then feed the Property Node.

Is it even posible that a new Property Node.vi could be made that would look much the same as the existing, but internally would look up the Control reference by Name using your method. I quess the one downside is that I couldn't just right click on the desired Control and select Create Property Node from the menu. Some loss in performance.

[David_L]

Funny you should mention this.  I made this as a community example subVI a few months ago because I ran into a similar problem.  

http://decibel.ni.com/content/docs/DOC-11868

[dbaechtel]

THANKS !

[David_L]

For all interested, this behavior was reported to R&D (CAR ID # 248914) for further investigation. Thanks for the feedback!