typedef and element cluster order

[LAVA 1.0 Content]

Hi,

Take a few seconds to do this :

- create a cluster with a few control in it

- save it as a type def (or strict type def)

- place it in a VI, and create a property node on one the control inside the type def

- save the VI

- open the type def and modify the order of element of the cluster

>> The property node is no longer linked the same object but to the object that now has the same index as before, idem for an event in an Event Structure.

This behaviour is surprising and not consistant because if the cluster is not a type def (or strict type def) the property node and the event remains linked to the same object, no matter its new order.

Noticed in LV 8.20

Anyone thinks this should be repported to NI as a bug ?

[Aristos Queue]

This is not a bug for typedefs. Typedefs are dumb. They have no memory. Other tools that index into typedefs store indicies or store names (which ever seemed most logical for that particular tool), but neither is satisfactory when the typedef gets edited. The typedef does not remember "This was 1, this was 2, and this didn't exist at all before" to allow other tools to correct themselves. The behavior you get is the behavior you get.

If you want a datatype that does know where its elements go from version to version, that's LabVIEW classes. That's, obviously, no help to you who is probably trying to do some amount of UI work. But when you encounter similar problems with the default value of your block diagram constants, know that classes can help you in that case.

[LAVA 1.0 Content]

QUOTE(Aristos Queue @ Aug 13 2007, 10:38 PM)

[...]

Typedefs are dumb. They have no memory. Other tools that index into typedefs store indicies or store names (which ever seemed most logical for that particular tool), but neither is satisfactory when the typedef gets edited. The typedef does not remember "This was 1, this was 2, and this didn't exist at all before" to allow other tools to correct themselves. The behavior you get is the behavior you get.

[...]

Hi AQ,

I do understand what you mean and don't expect the type def to be a magic tool, but I just wanted to point out that the behaviour is different wether the cluster is a type def or not. You say "The behavior you get is the behavior you get" well... Regardless of what classes can do, to me, the behaviour I get is a non-consistant behaviour ; this is what bugs me.

Now, this said, I guess you're right and I should free some time to learn to use LV classes ; that's on my roadmap.

[captain]

QUOTE(Aristos Queue @ Aug 13 2007, 08:38 PM)

This is not a bug for typedefs. Typedefs are dumb.

They are not so dumb: When using unbundle by name on a such typedef, I can change controls order without problem.

With LabVIEW 6.1, the behaviour is the same for a property node (properties nodes are mixed). But for an event, it give an error: event no more defined. I think it's a little less worst. I prefer to know when I do something wrong.

[TG]

QUOTE(captain @ Aug 14 2007, 01:38 PM)

They are not so dumb: When using unbundle by name on a such typedef, I can change controls order without problem.

With LabVIEW 6.1, the behaviour is the same for a property node (properties nodes are mixed). But for an event, it give an error: event no more defined. I think it's a little less worst. I prefer to know when I do something wrong.

I think it should be a bug.

Its also there in 8.2.1

I personally spent a lot of time tracking down logical errors

when I tried to use property nodes in Typedefs.

Reason: I did not know any better.

[Grampa_of_Oliva_n_Eden]

QUOTE(TG @ Aug 14 2007, 02:03 PM)

I think it should be a bug.

...

I think I would like LV to make all of the explicit ref's invalid to get me to look at what I may have missed. So I guess I am disapointed that it does not do so already.

I guess the only thing we can do is submit it as product suggestion and hope.

Ben