declaring variables and event structure issue

[tbob]

You did most of the work.  It is a pleasure to help someone who is willing to try compared to those who want us to write their entire vi for them.

[KSU Flyer]

In the listen case, event acceptValue...what should I wire to the acceptedValue indicator?  I want this to be the value set in the searchResults, not an empty string...do I need to have another shift register here?

Thanks so much!

-Mike

[tbob]

The last vi you posted does not have an acceptValue event case, nor does it have an acceptedValue indicator.  If you want to move the contents of selectedValue in one case to acceptedValue in another case, you can use a local variable of selectedValue.  Just right click on selectedValue icon and select Create - Local Variable.  Drag it to the other case.  Since you want to read from this local, you will have to right click on it and select Change to Read.  Then wire the output to the acceptedValue indicator.

I don't encourage the use of local variables because of potential race conditions, but in this case it is OK.

[KSU Flyer]

Crap, sorry, that was an older version...look at this one...I used another shift register to take care of it...I think! LOL

[tbob]

Yes that will do the trick.  As an alternative, the attached vi uses local variables instead of another shift register.  Both work, its just a matter of preference.

Also, in your acceptValue event case, the next state should be listen.

[tbob]

I just noticed you didn't have a separate default case in your state machine.  Consider the following.  In one of your states, you declare the next state to be "xyz".  However the main case structure has no "xyz" case.  What will happen will be that the next case will go to the Default case.  In your vi, you set the "listen" case as default.  This is kind of OK.  But what is better is to have a separate default case that catches instances where the state being called does not exist.  What if you made a typo when you typed search, and you typed "serch".  The next case will not be searh, it will be listen.  So to catch these errors, create a new case with a blank string or nothing at all, and set it to Default.  Right click on the case border and select Make This The Default Case.  The default case should create an error condition and call the exit (cancel in your vi) state.  If you make a typo, it will show up as an error.

[KSU Flyer]

Thanks again tbob, you're the best.

After reading your post on the default case...it got me thinking...whats the point.  I'm going to debug the subvi anyway right?  I would most likely find that sort of typo as the subvi wouldn't work as expected.  I don't mean that to sound unappreciative or dismissive.  Maybe I can't see it because in my instance their aren't many states?  I'm trying my best to understand...maybe this is just good practice?  Also, I notice a lot of the good code or built in functions have the ability to pass errors through them...I don't understand how this is used either.  Lord knows I need some formal Labview training. 🙂

[tbob]

Believe me,  it is best practice.  When your number of states grow larger, you will have more of a chance at creating a typo.  This will catch typos.  In your latest vi, you had a next state of acceptValue, yet there was no "acceptValue" listed in the case structure.  So it went to default "listen".  It didn't cause a problem then, but you still had an undefined case.  This will pop up to bite you sooner or later, so use the best practice method.

[KSU Flyer]

Read you loud and clear tbob!  Thanks man, if you were here I'd offer to buy you a beer!

[JÞB]

You might meet TBob at NI-week someday

Tbob- nicely done, even WITH local variables

 A LOT of good points came out of this thread- (hence the Required reading tag) -

1- data flow vs text paradigms.  both do have their advantages but, I NEVER miss a ";" in LabVIEW and find data flow to be more intuitive for myself. I think it is always better to "take the high ground" that is , use every advantage possssible.  G languages let me do just that!  And MY thought processes are not too unusual for any engineer.  (IMHO):smileyvery-happy:

2- Architectures: State machines, P-C loops, and what drives them!(enums, clusters, strings)  Tbob, Id urge you to not be so lazy creating a str-type def enum only takes a dozen clicks and saves key-strokes building the case structure (create> case for each ...)

3- pitfalls of LabVIEW,  (yes there are a few) or "how to avoid getting in trouble programming in G"  The style guide and help file refeances are GREAT

4- LabVIEW has great examples- use them

Message Edited by Jeff Bohrer on 06-04-2010 08:08 PM