called vi not running

[twayne]

Hello all. 

Here is my situation.  I have a Main Menu GUI to start my users on.  They have 7 options to choose from.  When they pick one I open up the one they want and close the Main Menu page.  On each of these sub-vi's there is a MAIN MENU button to take them back to, you guessed it, the Main Menu.  The problem I am running into is that when the Main Menu GUI opens back up, it is a clone and it actually stops running before the user can interact with it. 

I just cannot figure out what is gonig on.  Attached is a cleaned up version of the Main Menu GUI, and a test.vi that contains the code to go back ot hte Main Menu when you hit the button.  This is exactly what I am using in the actual vi's but there are so many sub-vi's that i would have to post to make it usable that I just put this together real quick.

Open the Main Menu vi and tell it yes or no to the real hardware popup, it doesnt matter in this case, then click the "Mode 4\5 - ESIL" button to launch the test sub-vi.

In the sub vi click the Main Menu button to go back to the main menu and you will see the problem I am stuck on.

Thank a million for any help or ideas.

[RavensFan]

Your main VI is set for reentrant when it shouldn't be.  That is why you are getting a new clone when you call it again.  go to  File/properties, execution and uncheck reentrant.  Try it again.

[twayne]

When I don't set it reentrant I get this error message:

Error 1096 occured at Open VI Reference in test 1.vi

Possible reason(s):

LabVIEW:  (Hex 0x448) The Open VI Reference function cannot prepare non-reentrant VI for reentrant run.

VI Path: C:\Documents and Settings\du402c\Desktop\main menu.vi

[Eugen_Graf]

I can't see your VI, but I think you have a 8-option openning VI-Refnum, if you don't want to work with reentrant VI, than open the reference with a default-option.

[twayne]

It took me a second to remember why I had that 8 option on there in the first place.  But in my real code, if I don't have that on there, my Main Menu GUI, when it starts back up, does not run and has a broken run arrow, though there are no errors listed.

[RavensFan]

Perhaps rather than closing the Menu VI's front panel, you should just hide it.

[johnsold]

I agree with Ravens Fan. Hiding rather than closing avoids the issues of what is running and when. With the event structure and infinite timeout the Main Menu VI does nothing and consumes no CPU resources while running but hidden.

I have attached modified versions.

[twayne]

That was one of my original thoughts, but I couldn't figure out a good way to implement it.  I tried just setting it transparent with the property for that but then when I would try to get back to it from the sub-vi I couldn't get it to consistently reappear.

[twayne]

Ah, thanks Johnsold.  I had not seen that FP.state property before.  That should work nicely.

[twayne]

Ok, turns out I still dont knwo what I am doing.  This didn't work exactly right in my real work so I was trying to play with the examples you provided.

Attached is what I changed, now I am getting an error when I try to reopen the Main Menu that says I can't change the state of a closed front panel, even though it should only be hidden, not closed.

What think you?