LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unexpected Behavior with TypeDefs

Solved!
Go to solution

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.

Murine Config.png

 

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").

Action FP.pngAction Murine Config.png

 

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:

  • Search for (and locate) the TypeDef Control or Indicator.
  • Delete it.
  • Using Quick Drop, insert it again using the name of the TypeDef.
  • Rename if necessary, change to Control/Indicator as needed.
  • Rewire in the Block Diagram.
  • Reconnect to Connector Pane.

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 

0 Kudos
Message 1 of 3
(2,611 Views)

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

0 Kudos
Message 2 of 3
(2,603 Views)
Solution
Accepted by topic author Bob_Schor

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.

0 Kudos
Message 3 of 3
(2,563 Views)