Why can't I create property nodes for item in STRICT typedef cluster?

[CoastalMaineBird]

I've tried this in LV7.0/WIN2k and LV 7.1/OSX - both versions work the same.

I have a TYPEDEF consisting of a cluster of items A, B, and C.

I have a front-panel instance of this typedef.

Under certain conditions, I want to disable and gray Item C, because it's not applicable.

So I need a property node connected to item C.

If the typedef is STRICT, then I cannot create such a property node - the menu item to create anything is just not there.

If I change to NON-STRICT, then I can create the property node.

I can change it back to STRICT, and the property node works just fine.

The question is, if the nodes WORK normally, why can I not CREATE one?

If there's some sense behind this, someone please point it out to me...

[Ben]

Hi Coastal,

From my understanding of LV typdefs strct and non, I think you may have uncovered a "hole" in LV.

As i understand it (please correct me if you know better!) strict typdefs are the same a non-strict except that the appearance of a strict is part of the typedef. All stricts of a type will all look the same. With this understanding I understand what you decribed as follows;

When you changed the control from non to strict, I THINK the VI should have broke.

This is the best I can offer for now,

Ben

[falkpl]

The difference between strict and nonstrict typdefs is that instances of the strict typdefs must maintain almost all the properities of the typedef. This means that changing properities of a strict typedef would by default violate the definition (at least how I precieve it. I havnot found great uses for the strict typedefs since it too restrictive for most applications but typedefs in general make programming Labview much easier. Typdefs Clusters work like STRUCTS of c. The nice part of strict typedefs however is that on autoupdate one change in the "look" (ie properities) of the definition is seen across the board on all references in an application. I have found that storing data structures for data flow is easiest with nonstrict typdefs and then presenting such information through custom controls works well. This seperates the data from the presentetion and keeps the program flexable, which is not the case when using strict typdefs. Hope this makes some sense.
-Paul

[CoastalMaineBird]

strict typdefs are the same a non-strict except that the appearance of a strict is part of the typedef.

Exactly. The physical arrangement of items in a cluster is part of a STRICT typedef, not of a non-strict. Things like decimal places, and other formatting are supposed to be locked under STRICT typedefs.

< DING > < Light bulb goes on >

Maybe THAT is why they are SUPPOSED to be inaccessible - if the number of decimal places is supposed to be locked to the typedef, then having a property node to set the formatting would go against that.

So I suppose enabling and disabling would also go against it, so they intended to block it out altogether by not allowing property nodes. But they didn't know what to do with property nodes created beforehand. So they still work.

At least it's plausible.

[Ben]

Just be forwarned that this "hole" may get "plugged" in a future release, unless no one reports it of course...

Ben

[CoastalMaineBird]

This means that changing properities of a strict typedef would by default violate the definition

OK, I can agree with that. App Note #159 lays that out. So how come you can still do it??

I just learned TYPEDEFS in the past 2 years or so. But I find myself switching a given control between STRICT and NON-STRICT a fair amount. Sometimes I want it STRICT, so all the instances follow the re-arrangement I did. But sometimes it has to be NON-STRICT, so I can get work done. So I find myself going to the TYPEDEF, changing something, setting it to STRICT, applying changes, then setting it to NON-STRICT and saving.

Seems like there should be a better way.

[CoastalMaineBird]

Just be forwarned that this "hole" may get "plugged" in a future release, unless no one reports it of course...

I hear you.

If it gets plugged, I'll just have to do what I now do sometimes anyway:
When I change the typedef, I set it to STRICT, make changes APPLY CHANGES, set it to non-strict and save it.

Hopefully if the STRICT typedef breaks the VI that has property nodes to it, the break will be repaired when I change back to NON-STRICT?

If there's a better way to do what I want, I'm all ears.

[falkpl]

I agree with you, It would be nice to be able to keep the non strict typedef auto-update and extend it to properities which effect the look of a control. I am not sure why you can change the properities on a strict typedef. A strict typedef should have private properities (can only be changed from within the definition and no public other vi scope for writing these values. I have in the past used a custom control for presentation purposes and contained the structure of the data to be displayed within the typedef cluster. This is not all that automatic since we need vi's to convert between the definition and control. Seperating data structure from presentation is much like XML where the file only contains data structure and a reference to a style for presentation. It would be a very nice option to allow nonstrict typedefs to have an additional auto-update properities which could be toggled on and off. I would be curious to here others opinions on how to keep data structure and presentation consistant across an application without being tied down to a strict typedef (allowing the optional change of teh presentation at runtime).

Paul