Darren's Weekly Nugget 03/16/2009

[PhillipBrooks]

Darren, how do you typically keep the enums and associated VIs 'synchronized'?

I usually place my typedefs and VIs in a single LLB file, but I know that some people are reluctant to use LLBs.

[Darren]

I don't understand what you mean by "synchronized".  With a typedef enum, any changes made to the enum are automatically propogated to all calling VIs.  Were you referring to something else?

[PhillipBrooks]

Sorry, it was a bad choice of words...

A change to a typdef typically happens when functionality changes. For example, a typdef'ed enum might consist of 'Yes', 'No' and 'Maybe'.  This typedef'ed enum was defined when creating a VI called 'Log to Disk.vi'.

I've always placed the VI and related enum in an LLB.  If I need to add a new case to my logger called 'Log if St. Patricks Day', I would edit my typdef to add the case, then edit the VI to handle the case.

I noticed in the VI Analyzer LVLIB that typdef's are contained in a single LLB, and the various VI Analyzer functions are each in their own LLB.  It seemed a bit unnatural to me that the typdefs are not part of the LLB in which they are used...

[Darren]

That's how I've always organized my projects...all .ctls go in their own folder (used to be LLB), and everything else is organized accordingly.  Makes it easy to find .ctls when they need editing, and in my experience, changing code to support a new enum value starts at the code, not at the enum, so I guess I've never really encountered a situation where I need to find all the places that use the enum.

And of course, LV Class advocates would argue that none of this is an issue if you're using classes to define your interfaces, since adding a new class should (theoretically) require no extra work in other areas to support the new functionality.

Message Edited by Darren on 03-17-2009 01:53 PM

[F._Schubert]

For both string and enum case structures, I could think about several tools using private methodes/properties to verify code:

enum:

* Report all enums that are not type def or strict type def

* Report all Case structures of enum kind that have a Default case

string:

* Give a list of all string constant values

* Give a list of all cases using strings

* Perform typo error check comparing the two lists.

Propably some of that is already implemented in the VI analyzer.

Felix

[crelf]

My SMs generally start as enum-based by default, but move to string-based only if they need to.  I use the enum ones for simple pre-defined SMs, but the strings allow me to consider funnelling multiple cases into one case (within ranges) that I can act on.  We also have a reuse library that makes writing SMs and QMHs easily (and swap info between them) so using a string-based architecture is the only way for us to go in that situation.  Sure, enums trap errors during development, but I don't think that is enough to stop me from using strings that I'm going to trap during ad hoc unit testing anyway.