hide/unhide radio buttons works in LabVIEW, not in executable

[RvG]

Hello,

I simplified a program I am using. When I run in lab view the radio buttons are visible or not (as programmed). But when I create an executable, this function is not working any more?

Do I need to make changes in the build settings?

best regards,

Rens van Geffen

I attached the maintest.vi (lab view program) and the executable as well in a zipped folder.

[RavensFan]

What are you actually trying to do here?  Your code involving the counters in the inner while loop doesn't make sense to me.  How are we supposed to operate your VI?  It doesn't seem to do anything when I try to run it.

[RvG]

THE problem I have is that I need to hide different radio buttons for user levels. It workshop fine when I am running in lab view. But when i create an executable it Does not work. THE VI i send is a simplified VI from the whole program i am using. Rens

[altenbach]

I agree that there is a problem after building an executable (even in LabVIEW 2011SP1).

somebody needs to look into this.

When setting to administrator, the buttons become visible when the application is stopped. This is too late!

(Or course your code is full of race conditions, unecessary local variables and value property nodes and overly complicated code, but even after a cleanup, I can reproduce the problem after building an executable)

[RvG]

Yes i know it is a dirty vi. But I only made it because I had a problem in a complicated vi, with lots of sub vi's etc. in that vi I have all wait functions etc.

[RvG]

Yes i know it is a dirty vi. But I only made it because I had a problem in a complicated vi, with lots of sub vi's etc. in that vi I have all wait functions etc.

[altenbach]

I think it is a bug and reported it in the monthly bug thread.

---

@RvG wrote:
Yes i know it is a dirty vi. But I only made it because I had a problem in a complicated vi, with lots of sub vi's etc. in that vi I have all wait functions etc.

---

I did not care about any wait function. I was just objecting about the overuse of value property nodes and that exceedingly complicated inner while loop construct that really does not do that much.

For example, your upper case structure contains writing to two value properties that exist in all cases, while the actual terminal just sits there outside the loop. The cases only need to contain what's different. Shared code elements belong outside the case! Instead of writing to value properties (which is synchronous and resource intensive), you can just write to the indicator terminal instead. Right?

In parallel to writing to the "group", you also read from another value property instance of the same. Since this happens in parallel to the case structure, you will read a stale value, and not what has been generated by the case structure during the same interation.

My code modification shows some of the simplications that can be done. Also note that data dependencies enforce the proper execution order.

Writing to the visible properties only needs to be done when the situation changes and not with every iteration of the loop. Once written, these proerties stay until changed to something else.

In summarry, these are just some recommendations. They will not fix the LabVIEW bug you exposed. 😉

[RavensFan]

---

@altenbach wrote:

I agree that there is a problem after building an executable (even in LabVIEW 2011SP1).

somebody needs to look into this.

When setting to administrator, the buttons become visible when the application is stopped. This is too late!

---

I saw this same behavior even in the development environment.

[RvG]

I thing that came up my mind. I performed this action (hide/unhide radio buttons) by dsc security levels. Because I found the price for runtime dsc module quite expensive for just the login (username and password) that I deside to rewrite this part, so I don't need the dsc module. I never took away the security levels on the buttons them selves. Might this be the problem?

[RavensFan]

That seems like a likely cause.

I have the DSC module, but my security names and logins aren't going to be the same as yours.

I would try disable that security aspect if you can.  And if you can't, just delete the controls and recreate them new.  See if that fixes the problem.