Deleting a control from a typedef Cluster

[1984]

Hi Community,

I have a typdef cluster with several control elements. What I have found is that if I delete an element from the typedef then the property nodes in my main VI referring to the individual elements of the cluster are getting messed up.

Normally I would expect that if I delete an element from the cluster then after applying the changes I would see a broken wire wherever I previously used that deleted element. But instead my existing property nodes start to point to different elements of the cluster.

For example:

I have ctrl1, ctrl2, ctrl3 and ctrl4 in my typedef. After I delete ctrl2 it can happen that property nodes for ctrl3 gets disappeared and the instaces of ctrl4 will start pointing to ctrl1.

This was not an actual example, but I guess you get the point. This issue is exteremly inconvenient as I need to check the entire code again and again once I delete something from the cluster. Plus its very error prone as well. The problem I see is somewhat similar but not the same as this:

http://forums.ni.com/t5/LabVIEW/Deleting-Control-from-Type-Definition-casuses-many-misreferences/td-...

(I have tried to convert the typedef to a strict type def, but that doesnt make a difference)

Do you guys have an idea how to get rid of this?

thx.

UPDATE: This topic talks about the same, although doesnt seem to resolve the original number. So by deleting an element I get the cluster elements reordered. But why does it mess up the property nodes and how can I fix it?

http://forums.ni.com/t5/LabVIEW/If-I-reorder-elements-in-a-typedef-cluster-will-all-the-bundles/td-p...

[RavensFan]

Go around your code and delete the wires and terminals within all clusters that use that particular element.

Only after doing that do you go and delete the item from the typedef.

[1984]

Ok I have tried that and it doesnt seem to help. I may have not been careful enough but anyways this looks extremely tedious work to find all instances in an application. What if I need to renumber the order in the cluster for each element. This means I will need to spend hours on wiring / rewiring each and every instance again.

[Bob_Schor]

When you change a TypeDef, it necessarily changes all VIs in which this TypeDef was used.  If the VI in question would be influenced by this change (for example, if an Enum, and you wired it to a Case Selector, or a Cluster and you manipulate it), you should probably examine all "use" cases.

Here is a "Brute Force, but Effective" way to do this (one that I routinely use, myself).  I'm assuming that you are using LabVIEW Project, which provides a convenient access to all of the VIs that you have coded into your application.  Create a Tree VI in the Project, and put every VI (you don't need TypeDefs in there) that you use inside this Tree VI.

If you restart LabVIEW and open your Project without opening the Tree VI, everything will be as before (so you've not impacted your working code).  However, during Development, if you open the Tree, you now have all of your VIs in memory.  Open your TypeDef (which is not in the Tree), and do a Find All Instances.  By repeatedly typing Ctrl-G, you will be transported to every place this TypeDef is referenced, which should greatly speed up finding/fixing all of the inconsistencies arising from the changes you made to the TypeDef.

Note that if your code has "natural divisions", you can make Trees for each part, and then a "Tree of Trees" (hmm, should you call it a Forest), allowing you to work with sub-sets of your code.

Bob Schor

[Intaris]

It is tedious and it is dangerous.

This kind of behaviour has burned me in the past.  Make sure to test well after making any change of this kind.  Spending a coupld of hours now seems like a waste of time but tracking down the problems caused by this kind of trvial change can take DAYS if you don't pay attention to the testing ASAP.

LabVIEW does some weird things sometimes and I certainly don't think this behaviour is intentional.

[1984]

It could be very dangerous... if lets say I want to output 24V with a power supply and heat something up to 75C and after changing the cluster these get swapped and remain unnoticed then I will output 75V and set the temp to 24C.

Do you think this should be filed as a bug to NI?

[GerdW]

Hi 1984,

Do you think this should be filed as a bug to NI?

No - as it's a bug of the programmer…

Usually you design your program flow and all needed data structures BEFORE you start to code!

[1984]

I like your answer lot. Lets just remove the highlight execution, pause etc features as well, as a programmer should not make a mistake.

To elaborate this more what if the programmer actually have layed everything out correctly but the specs change?

[GerdW]

Hi 1984,

then you need to change your program - and you need to debug ANY dependencies of the changes you maid…

(I usually have to add new elements to a typedef, which is no problem at all…)

[1984]

I agree that I need to debug the code.

The problem is that labview creates false dependencies... I dont just need to debug the parts where I have used the deleted control I practically need to go thru ALL the code uses property nodes / references of the given typedef as they are tend to get messed. 

Its like if I would delete an element from an array and as a result the rest of the elements would get scrambled.