07-09-2017 02:37 PM
I use TypeDefs a lot, in particular for almost every Cluster I define. Some of these Clusters have Default Values that I define as part of the TypeDef. For example, here is a Configuration TypeDef that has three Clusters as sub-parts, for Experiment, Balance, and Camera, each with several parameters.
In my code, there are numerous times when I use this TypeDef as a Control, an Indicator, or a Constant. For example, here is the Front Panel and Block Diagram of an Action Engine that lets me Define, Use, or Replace this Config (Define means "Set to the Constant defined by the TypeDef", Use means "use the Defined or Replaced Value", and "Replace" means "Use and remember the Input Value").
Note that the TypeDef Cluster is shown in "Iconized" form, really handy for self-documentation and taking up little space on the Block Diagram.
So here's the Unexpected Behavior (which may well have been there all along, it just didn't Byte me where I sit down). I recently changed the TypeDef, specifically the values P-On and P-Off. When I looked at the Control in this Action Engine's Front Panel, it showed the original value (which didn't surprise me). However, I couldn't use either Quick Drop's Replace nor the Right-Click Replace command to put the new TypeDef (with new defined values) in its place. Instead, I had to do the following:
But that wasn't all! I was a tad careless -- my Search also turned up the TypeDef Constants (such as the one shown on the Block Diagram, above), which I didn't realize also needed to be replaced.
So here is my question -- is there any reason that I can't "force-replace" a TypeDef Control, Indicator, or Constant with the named TypeDef recognized by the Project, either using QuickDrop's Replace command or a Right-Click "Replace"?
I realize (partly) where this "misconception" of having TypeDef changes propagate through the code arises -- changing part of an Enum forces changes everywhere. [Hmm -- what if I changed the spelling on a Cluster Element? I'll have to try that].
Does anyone have any thoughts or suggestions? [I'm going to try changing a Cluster Element name and see if that "fools" LabVIEW into doing a propagation, and will report back shortly.]
Bob Schor
Solved! Go to Solution.
07-09-2017 02:47 PM
Changing the name of a Cluster element does propagate, but changing the default value does not. Actually, I don't have to be quite as labor-intensive as in my previous post -- I can instead search for the TypeDef, change the value of the Indicator, Control, or Constant, then (for Controls and Indicators) Save as Default.
Live and Learn.
BS
07-09-2017 05:55 PM - edited 07-09-2017 05:57 PM
I remember this coming up before and this was known and intended behavior. Typedefs only define the type, not the default values.
If you want to use a data type that propagates default values you have to use LVOOP classes, as their default value is part of their data type.
Ever since I read that, whenever I drop a typedef cluster constant down that uses any values other than the LabVIEW defaults (i.e. all zeros/blanks/nulls etc.) even if they are defaults for that particular type definition, I always expand the cluster to show the whole thing. I actually made a quick-drop plugin that expands a cluster constant and forces all elements to show their labels to the right, and then auto-arrange the whole thing vertically.