LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

run time menu error

Solved!
Go to solution

Hi Everyone,

 

I ran intoanother seemingly simple problem, but I can't get my head around it.

 

I want to implement a simple run-time menu for a control where the user can select different options.  RTM edited and set to default no problem.  Right-click on the control when running, the correct menu appears, no problem.

 

Problem occurs when I want to set the menu entry to checked or unchecked. My problems are:

  1. Why does the menu refnum not appear in the "Menu selection (user)" events?  Do I have to intercept the menu reference from the "Meu activation?" event for the control?
  2. When I intercept the reference this way (reference changes with each menu selection) I get "Error 1160 Invalid menu" when I try to change the elements to checked or unchecked......  I store the reference in a shift register for later usage when a different menu event is fired.

 Can someone please have a look at this VI and let me know what I'm doing wrong?

 

Why can't the run-time menu simply be read from a control's property node?  That would be so easy.   Or if I know the filename for the rtm, how do I get a valid reference to it?

 

Sorry is these are silly questions, but I just can't figure it out at the moment.

 

All VIs are 8.2.1.

 

Thanks

 

Shane.

0 Kudos
Message 1 of 16
(4,037 Views)

OK, as usual, even asking the question goes towards solving the problem......

 

I found this link which states that the menu reference is only valid within the single "Menu activation?" filter event case.  WHY?

 

Does this make sense?  Shouldn't it also be valid in the "Menu selection (User)"  and "Menu Selection (App)" cases?

 

To add insult to inujury, the Item Tag data is not presented in the "Menu activation?" filter event.....  

 

Smiley Mad

 

Workaround anyone?

 

Shane.

Message Edited by Intaris on 10-02-2008 08:53 AM
0 Kudos
Message 2 of 16
(4,035 Views)

Intaris wrote:

OK, as usual, even asking the question goes towards solving the problem......

 

I found this link which states that the menu reference is only valid within the single "Menu activation?" filter event case.  WHY?

 

Does this make sense?  Shouldn't it also be valid in the "Menu selection (User)"  and "Menu Selection (App)" cases?


What would you want to do with the menu after the user has selected something and the menu is gone?

To add insult to inujury, the Item Tag data is not presented in the "Menu activation?" filter event.....  

 


What is Tag data?

In the 'Menu activation?' event you can build or alter a menu, and nothing is selected yet so no Tag is valid yet.

 

Ton

Message Edited by TonP on 10-02-2008 05:24 PM
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 3 of 16
(4,020 Views)

Well, I was approaching it similarly to the normal menu for a VI which has a persistent state.

 

I think I simply need to go at this differently.

 

If I am correct, I intercept when the menu is created and then check the options required (or uncheck accordingly).  I simply want to give the user a visual feedback as to the current selection status of the options being presented.

 

Take for example the "Autoscale X" option of a graph.  When you right-click, it's clearly visible which options are selected and which not.  I want to do something like this.  I thought a rtm would help simplify the code, but it seems I simply need to do the current (Before the user clicks on something) checking and unchecking in the "Menu activation?" filter event.....

 

It's a bit clearer for me now.  I was thinking of setting the ckeckbox immediately after selection to have a logical grouping on my block diagram.  This way two different event cases are responsible for implementing the functionality.  I suppose I can live with that.

 

The option I was LOOKING for was to have a set of boolean tags which could all be handled using a single function for checking or unchecking.  This would have been a bit more flexible.  As it is, I have to hard-wire the Item Tags into the code in a seperat case to the actual code being executed.....

 

Shane.

 

PS Here's my code with the implementation as described.... I think it would be easier the other way 'round though.....

Message Edited by Intaris on 10-02-2008 11:05 AM
Message Edited by Intaris on 10-02-2008 11:06 AM
0 Kudos
Message 4 of 16
(4,009 Views)
Solution
Accepted by topic author Intaris

"When I intercept the reference this way (reference changes with each menu selection) I get "Error 1160 Invalid menu" when I try to change the elements to checked or unchecked......"

 

Do those changes in "Menu selection (user) activation event ?"

 

The  menu  "Menu selection (user) event " is after the display has been done, so it is normal not to be able to place a check (do a change)

Message 5 of 16
(4,003 Views)

The fact that the menu is displayed and not being able to place a check seems logical enough.  It's possible with a standard VI menu though.....

 

The change in checked status is updated only when the particular menu entry is re-drawn though so it's not really pretty.

 

The fact that a VI menu can retain its state whereas a control menu cannot is perhaps somewhere in the NI course material, but I've never come accross that info before.....

 

I've re-thought the problem and am implementing the solution so that it works (always the best way Smiley Tongue)

 

Shane.

Message 6 of 16
(3,996 Views)

Intaris wrote:

The fact that a VI menu can retain its state whereas a control menu cannot is perhaps somewhere in the NI course material, but I've never come accross that info before.....


You are right !

I had not noticed that before.

 

0 Kudos
Message 7 of 16
(3,986 Views)

Maybe you should post a suggestion to NI.

I think the control menu should retain it's state (like vi menu)

0 Kudos
Message 8 of 16
(3,974 Views)

It would be a lot of memory that would be claimed by the menu. For a graph alone it would mean holding the data for at least 10 menus...

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 9 of 16
(3,951 Views)

Why memory for 10 menus?

 

Surely a graph has only one active menu at a time?

 

Shane.

0 Kudos
Message 10 of 16
(3,948 Views)