Strange cluster property node behavior

[tuned99]

Encountered a strange phenomenon that I've been unable to recreate.  Please refer to the attached vi (Labview 7.1.1).

I am taking some header file data and parsing out its contents to various indicators inside a cluster.  I am using the bundle by name node so it requires that I have a cluster input as well as the output.  To do this, I use a property node->value to supply the cluster format and the output goes into the cluster indicator.

Recently, I added another indicator into the middle of this cluster and reordered them accordingly.  Somehow, the property node associated with it continues to show the added indicator at the bottom of my list of indicators rather than in the order I wanted.  In other words, the indicator order in my property node->value did not correspond to the actual indicator order.  The dataflow was not broken so I assumed things were ok until we actually tried using it and all of the data after my added indicator was corrupted.

I have fixed this easily by switching from a property node to a local variable.  However, the question still nags me as to how I was able to generate this in the first place.  My attempt at recreating the problem generates a broken dataflow as should be expected.  Is this some freak bug?  Was I wrong to use a property node in this situation?  Any comments are appreciated.

Message Edited by tuned99 on 11-01-2005 10:22 AM

[mfitzsimons]

No bug, standard behavior.  Make your cluster into a Strict Type Def.  When you reorder the Type Def and Apply Changes, items will be in the list in the correct order.  Type Defs are more flexible and easier to maintain than just plunking down clusters in the program.

Matt

[tuned99]

HI Matt, I appreciate your response and I may wind up having to use a type def to prevent this.

However, my cluster is not a separate customized control with which I can turn into a strict type def.  If this is standard behavior, I am having difficulty recreating it.  In a brand new VI, if I were to generate a cluster, create its property node, wire it up in the same fashion, and reorder the items within the cluster, the dataflow breaks.  Why does the dataflow break here and not so in my previous example?

[altenbach]

Personally, I don't like these types of "circular" codings. Why don't you right-click on your cluster terminal and create a diagram constant to be wired to the cluster input?

[tuned99]

Because... that would be just too easy. 

Actually, in my original example, my cluster has many elements and I was just trying to conserve white space in my block diagram.  I was also hoping to achieve some sort of typedef-ish behavior without explicitly using a typedef.

I will probably resort to some sort of strict typedef constant in the future but I still was hoping to get to the bottom of this in case it pops up again.

[Ben]

I believe this is a bug were the cluster from the "value" property node does not adapt when the control is editted.

I reported this bug a while back so I am not going to start that logging over again.

In the attached jpg you will see the definition of the cluster as it comes out of the "value" property node. This does not match up exactly with the control you are wiring it too so LV shows you a coercion dot to let you know.

I agree with Christian that this is an odd circlular construct.

It is not broken in the original version because LV found enough of the right data types that it got by with just coercing. In your other example LV could not get the fileds to match-up so it gave up at let you know about it.

How to avoid:

Use type-def's but be aware there is another similar bug in LV 7.1 and prior were LV will select the WRONG fields in the bundle by name when the type-def is changed. This has been fixed in LV 8 (I have been told).

Summary:

Yes a bug.

Use type-def

Watch for new bugs if not using LV8 or better.

Ben

Message Edited by Ben on 11-01-2005 01:19 PM

[LV_Pro]

On your first example diagram when I create a property node from the existing control, then reorder the control it doesn't break the diagram. I do get a coercion dot where the bundle by name goes into the control though. Odd.Type defs help, particularly if there is a chance that this cluster will be used elsewhere in your program. I too have had a couple of weird instances, with clusters, that I wasn't able to recreate elsewhere.

P.M.