10-02-2008 08:41 AM
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:
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.
Solved! Go to Solution.
10-02-2008 08:49 AM - edited 10-02-2008 08:53 AM
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.....
Workaround anyone?
Shane.
10-02-2008 10:20 AM - edited 10-02-2008 10:24 AM
What would you want to do with the menu after the user has selected something and the menu is gone?
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?
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
10-02-2008 11:02 AM - edited 10-02-2008 11:06 AM
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.....
10-02-2008 11:11 AM
"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)
10-02-2008 11:28 AM
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 )
Shane.
10-02-2008 01:14 PM
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.
10-03-2008 12:55 AM
Maybe you should post a suggestion to NI.
I think the control menu should retain it's state (like vi menu)
10-03-2008 02:48 AM
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
10-03-2008 02:49 AM
Why memory for 10 menus?
Surely a graph has only one active menu at a time?
Shane.