LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

wrong run-time menu

Hello,

First time poster here-- I have LV8.5 Base and have an issue with custom run time menus.  I have a "main" vi that will launch other vi's upon the press of a button.  The sub-vi's have a common run-time menu called program.rtm.  Three of the vi's (here on known as "good1", "good2", and "good3") will launch and bring up the custom menu.  The fourth (from here on known as "bad1") when first created it would bring up the custom menu. But I realized that I had forgotten to make bad1 reentrant as good1,2,&3 are, so I made that change rebuilt the code and now. Bad1 no longer brings up the custom menu, but instead displays the default menu.  

 

In all the sub-vi's I use the Vi "Current VI Menubar" to get a reference then use "Get Menu Selection" to in polling loop to capture the menu selection.  

 

I believe all the sub-vi's have the same properties:

custom appearence to show menu, show front panel when called, close afterward

reentrant execution (as there can be multiple instances open at a time)

 

Main vi:

is not reentrant

doesn't have a menubar

in block diagram all sub-vi's are set with properties: show front panel when called and close afterward

 

Interesting side-note, when I make a chinge in the code and run "bad1" in development mode it shows the custom menu until the the vi is saved, then the vi show default when run....

 

It is unrealistic to post the vi's here, I could create a something to simulate what have done if it helps.. let me know...

 

Best Regards,

almac 

0 Kudos
Message 1 of 5
(2,186 Views)

Hello Almac13815,

 

I will need to take a look at your code screens shots or better the simulation in order to assist in this matter. 

 

Regards,

 

Izzy O.

Applications Engineer

National Instruments 

0 Kudos
Message 2 of 5
(2,162 Views)

Thanks, I will try to get something posted later today...

0 Kudos
Message 3 of 5
(2,151 Views)

Attached are screen shots for the menu handling code for good1, bad1, and the launch section of the code for the main.vi.  In the launch code the good1 is in the bottom loop and bad1 is in the upper loop.  Pretty simple stuff, set corresponding led for the case string. If statement to handle code when led is true....

 

Another interesting aside, I just remembered that I had the same problem with good3 as bad1until I added the error out indicator as shown in bad1.  Once I added the indicator to good3 it was fine, which is why it was added when I wrote bad1.  I had intended to go back and add it to good1 and good2, but haven't found the time/need.  

 

I did have some really elaborate code to catch and display any errors messages in bad1, but I only caught an error once and it was under some strange condition in development mode which I was unable to dupllicate.  Deleted that code in frustration....

 

Best Regards,

----almac----

 

 

Download All
0 Kudos
Message 4 of 5
(2,139 Views)

Hello Almac13815,

 

I think the best course of action would be to create two simplified cases of the VI as you previously suggested. One that shows the proper behavior and one that does not. This was if you attach them we can help to trouble shoot the source of the issue.  Also by breaking down the code you might find more insight into what is going wrong with the code.

Wear
National Instruments
Product Support Engineer
0 Kudos
Message 5 of 5
(2,104 Views)