Darren's Weekly Nugget 03/09/2009

[PaulG.]

I'm in the enum camp myself. I resort to a string state machine only when I need something really quick and dirty for a small vi.

[Darren]

Rolf:  Thanks for the explanation on the string range issue.  I'm pretty sure I heard that explanation before and just forgot (since, as I mentioned, I don't think I've ever used ranges on a string Case structure).  And it is a "reasonable" explanation, as I suspected.  🙂

Ben:  String Case structures were added in LabVIEW 5.0.  Probably went under the radar, with everybody talking about Undo.

Everybody else:  Next week's nugget is on Enum Case structures, so I'll chime in on the strings vs. enums debate then.

Message Edited by Darren on 03-10-2009 10:32 AM

[tbob]

Let me add my 2 cents worth since I hardly have time to participate in the forums anymore.  I once had a case where I wanted to match a range of single characters, like a through f.  I wired the string into the case structure and for the selector I used "a".."f", "f".  This made "f" inclusive.  I could get the same results using "a".."g", but it is misleading.  Keep in mind that only one character was being input to the selector, not a string of characters.

[Darren]

---

tbob wrote:
Let me add my 2 cents worth since I hardly have time to participate in the forums anymore.  I once had a case where I wanted to match a range of single characters, like a through f.  I wired the string into the case structure and for the selector I used "a".."f", "f".  This made "f" inclusive.  I could get the same results using "a".."g", but it is misleading.  Keep in mind that only one character was being input to the selector, not a string of characters.

---

Great idea, tbob.  I didn't think of that, but it makes sense, and you're right...it's more readable than "a" .. "g".

Message Edited by Darren on 03-10-2009 02:30 PM

[GregSands]

What do you mean by a Polymorphic Queued Message Handler?

[tst]

---

parthabe wrote:

---

tst wrote:

Enums also potentially have this (e.g. if you delete an element from a typedef enum, all the instances where that element was used will be automatically changed for something else)

---

Even then, the case structures that use these deleted names will turn red & break the code.

---

But only if you delete from the end of the enum. If you delete from the middle, it replaces the values automatically.

Personally, I don't have a real problem with this for two reasons:

1. I try not to delete entries from enums.
2. I try not to have a default case when working with enums. This means that if the value of the case selector changes, two frames will have the same selector and the code will still break.

[Ben]

---

tst wrote:

...

1. I try not to have a default case when working with enums. This means that if the value of the case selector changes, two frames will have the same selector and the code will still break.

---

For the casual reader please stop and take note of ts'st statement. The practice of NOT using a defaults to handle enum cases is a powerful technique that will

let LabVIEW help you maintain your code.

When coupled with a "Tree.vi" you can tell very quickly if a enum change will affect more code than you originally thought.

Ben

[parthabe]

---

Ben wrote:

When coupled with a "Tree.vi" you can tell very quickly if a enum change will affect more code than you originally thought.

---

I m NOT able to understand this point.

[Ray.R]

Well said Ben & tst.

No matter which method is used (strings versus enums), if it is not well understood by the programmer (most cases) with all the potential caveats, then bugs can and will be introduced.  Unless thorough testing is done to fully vaidate that portion of the code.

I don't think that most LabVIEW programmers actually realize how powerful the language is and all the tricks that can implemented with it.  Heck, I don't think I even skim the surface (hope it's the right expression) concerning all the potential tricks to implement solutions with LV.  That's why these nuggets are important.

R

[Ben]

---

parthabe wrote:

---

Ben wrote:

When coupled with a "Tree.vi" you can tell very quickly if a enum change will affect more code than you originally thought.

---

I m NOT able to understand this point.

---

Hi Partha,

I am concidering changing my user name here on the NI forum to match my name on LAVA "neBulus" since it seems I do that pretty often (what the hell is he talking about?!" )

When ever I use a term that you do not understand you could try checking my tags found here. The link for the "Tree.vi" entry takes you to here where you will find a link to this thread by Greg McKaskle from back in 2000. There he uses the term "FakeRoot VI" Mike Porter also calls these "Catalog.vi"s.

So what is a Tree.vi?

A Tree.vi is a VI that is never intended to run that contains your top level VI as well as any dynamically loaded VIs or templates. It is used to ensure that all VIs used by the application are runable simply by opening its FP and checking the run arrow. If I change an enum used by a dynamic VI and it breaks the dynamic VI, then the Tree will break as well.

How to use it?

In pre LV 8...

Open the Tree.vi and keep it open while you are coding. As you update enums a cluster type defs the Tree will let you know if you broke any of the required VIs because they will all be in memory and will get updated as you work. Paying close attention to the dialogs when closing up VIs is a good way of tracking how extensive your change was.

In post LV 8...

The logic used to resolve type def changes (specificly deletes and name changes) changed so "working with the tree open" (as I taught my boss) can lead to issues with bundle and unbundle by name. So in post LV 8 edits to type defs should be done with the callers closed and saved before opening the callers. So I open the Tree.vi after the changes to let everyone "know about the change".

Note:

I never did figure out a good way to use a Tree.vi to ensure LVOOP classes are all happy. Has anyone "cracked that nut"?

Ben