Community Nugget 5-Mar-2007

[pincpanter]

Wow! TonP's code opens, if not a new world, at least a new country to me! I usually managed getting enum strings in a more dumb way.

I also use typedefs extensively during the earlier design stages. I often start creating my data structures just after having choosen the overall program architecture, before writing any other code! This step also helps me to focus what was left out in my analysis.

I would like to add a sub-nugget to Ben's very good work.
When treating cluster typedefs (one of the most common cases), using Unbundle by Name and Bundle by Name instead of normal Unbundle and Bundle nodes helps you to keep your code valid when you change the typedef (unless you are removing cluster members, of course). These nodes are resilient to many changes, like altering member names, numeric data representation, control reordering (this last may be needed  sometimes, mainly for Strictly Typed typedefs).
But don't rely too much on this feature! If you are making extensive changes to the data structures, LabView can be "confused" and scramble all Unbundle by Name and Bundle by Name nodes; for example, if you change member ordering AND member names at the same time, your nodes will be corrupted; I verified this up to version 8.0.1.
So the final word is: make changes in steps! in the example above, make sure that all vi's using the typedef are in memory, then change member ordering, then Apply Changes and save, then change member names, then Apply changes again.
I got this problem once when I "inherited" a set of typedefs that did not satisfy me for their unconsistent naming and order. It may become a nightmare if the application is very large and you don't have a recent backup.

[tst]

Nicely done, Ben.

---

@TonP wrote:
Using 1$s allows me to reuse the first input twice

---

Unfortunately, this only seems to work in recent versions.

[TCPlomp]

Yes version 8.x if I recall correctly.

Ton

[shoneill]

I'd like to take this opportunity to agree wholeheartily with what Pincpanter wrote.

Defining the data before coding is something I also (try to) do, but this is something which can of course be done without Typedefs.  The real bonus of Typedefs comes when it's time to make those inevitable unplanned changes to the data structure.  Having already typedeffed (sp?) everything saves a WHOLE LOT of work.

Also the "automatic reassignment" of cluster names within an input and output bundle can be really annoying.  These are the kinds of bugs which can really hurt, taking ages to hunt down since the mistake is by no way apparent.  Is this still present in LV 8.20?

Shane.

[Ben]

Wow, so many good replies so little time.

Scott,

Thank you sharing the details of your fix. That is an elegant solution to having the best of both worlds.

Guenter, Pinc, and Shane,

I think you are telling me that you start to define you data structures before wiring! I was hoping that I was not alone in that step. It helps me define the functionality of my "fuzzy clouds" and how they interact. The dynamic update of type def's let's me move boyond that phase without having to worry about if I missed anything.

Ton,

Nice example of cross application type definitions! I find the customized icons allow my thoughts to focus on the work being done rather than "how is it being done".

Re: Type def update bug

LV had this problem prior to LV 7.1. I concidered it amoung the worst type of bug since it was "silent but deadly." I have not seen it since LV 7.1. If you have seen this issue since LV 7.1, PLEASE POSTY AN EXAMPLE so we can get this fixed.

Thank you all for bumping this Nugget up a notch with your replies!

Ben 

[Joe_H]

Ben,

Thank you for a great nugget. I think I have climbed up a notch on the LV food chain with the knowledge that you have given.

Woderful post.

[Ray.R]

Very well done Ben!

I will need to explore this very shortly with a new project!

Thanks,

RayR

[Ben]

Joe and Ray,

I look at is a "boot-straping" the LV community to a higher level.

Here is an example that clearly illustrates the benefits of wrapping the type def's in a sub-VI.

The type def that was wrapped up is nice and neat. Meanwhile the cluster constant I did not wrap-up EXPLODED!

Ben

Message Edited by Ben on 03-05-2007 10:25 AM

[Ray.R]

Thanks Ben,

You gave me an ideas for my project.

RayR

[parthabe]

Hi Ben,

Excellent post, Sir.

You re really not only the master of SD ( State Diagrams ), but TD ( Type Defs ) too.

Where is CC ?! Is he in hibernation ?! U Cute Cocoon, come out please...

I'm thinking that U re in the pipeline for the next nugget.

Regards,