Ring list incomplete in EXE?

[chuggins1434]

Hello all,

I have an odd occurrence... I have two separate ring controls in my VI.  On my development laptop they operate as expected whether the VI is running or not (I have them so our techs can make a couple of selections before starting a test).   However, when I build the exe, they're missing the last option in each list... So, I added a blank option at the end of each list and rebuilt the exe... now they work properly, but don't show the last blank selection option.  

Is this a bug in LabVIEW or am I missing something?

Thanks!

Chad

[GerdW]

Hi chuggins,

mind to share an example VI with rings same/similar to yours?

[chuggins1434]

I dropped my rings into a little sample VI... they still have the empty selection at the end...  The hide/show at run is what I'm doing so that the techs can't "adjust" them during a test.

[GerdW]

Hi Chad,

what's the point of using rings when you hide them while the VI runs?

How is your user able to edit their values???

Btw. your rings are set to NOT "allow undefined elements at runtime". That's the reason they hide those empty (aka undefined) elements! Open the properties dialog and choose the "Edit items" tab…

[chuggins1434]

GerdW,

Thank you for the response!

I use the ring so that they can change the values before they start the VI, but hide them so they can't change it during the test.  ...basically, it's just the first way I found to do it... if there's a better way please feel free to share, I'm always good to try something new.  🙂 

It's not that they're hiding the extra elements at the end, it's that it won't show the last option if I build the exe without the blank element at the end.

Thanks!

C

[chuggins1434]

...I should also note that this is about my 5th revision of this particular VI and this is the first one that's exhibited this behavior. 

[GerdW]

Hi Chad,

---

@chuggins1434 wrote:

I use the ring so that they can change the values before they start the VI, but hide them so they can't change it during the test.

---

Usually your users should only see a running VI or even better executable. And your program should allow to select items before actually doing some work. (You don't need to "run" Word to be able to edit a document.)

So there should be a state where the user can change settings while your program waits for a "start action" button and a state where the actual work is done. So a state machine might help…

Btw. when the items in your rings are fixed at development time of the VI you should use (typedefined) enums instead. Rings are useful when you want to change/define the items at runtime, like when loading the options from an ini file…

[chuggins1434]

My lab techs only get access to an executable... So that keeps them out of most trouble.  

I have them select which bench/stand they're on so that when the VI runs it's using the correct Task for which hardware set they're using... I'm guessing that this is just considered bad practice? 

I guess I'm using the state of running and not running the exe in leu of using a state machine setup... again probably bad practice...  correct?

[GerdW]

Hi Chad,

---

@chuggins1434 wrote:

I guess I'm using the state of running and not running the exe in leu of using a state machine setup... again probably bad practice...  correct?

---

Yes.

As I mentioned before:

Do you open MSWord, put a filepath somewhere and then actually start MSWord to be able to edit the document? No, MSWord is running right after starting…

Do you open a webbrowser, place a URL into the address line and then start a "RUN" button somewhere to start browsing the web? No, the browser is running right after starting and is even suggesting URLs as soon as you start typing…

Do you know any (reasonable) software that allows user interaction while in "not running" state???

[chuggins1434]

I never thought of it that way...   Excellent point.  I'll update with my next iteration.  Thank you for the point in the right direction!  🙂