Changing runtime menu of a control programmatically.

[Doug M]

lanmat,

I'm not sure what your end goal is, but let's think about it this way -- the shortcut menu is completely dynamic and has to be rebuilt every time the user right-clicks on the control.  If you want a checkmark to appear next to a menu item, you have to use the Set Menu Item Info VI every time the Shortcut Menu Activation? event is handled.  Use local variables to keep track of what the current state of the checkmark is for each menu item and write to the Set Menu Item Infor VI for every menu item to set its checkmark property.  Now anything in your code, whether the user actually selecting the menu item, or something completely unrelated, can affect whether the menu item will have a checkmark and it will appear this way the next time the user right-clicks the control to bring up the menu item.

Hope this helps!

[RVallieu]

Using this method it is easy to change the run-time menu of a control - but I have a need to restrict the menu items of the plot legend and can't seem to get to the run-time menu option for this sub-item of a graph.

Is there actually a way to get to this menu?

I'd rather not have to build a whole custom Plot Legend myself.

[Doug M]

I looked for a way to get a reference to the Plot Legend and couldn't find one, so the only way I can think of doing this would be to check against the screen coordinates of the click to see if it was in the area of the plot legend, and if so repopulate the shortcut menu.

[MrJackHamilton]

A lot of issues with the shortcut menu would be solved by allowing the 'MenuRef' to be accessable from any Event Structure assigned to that control. Having the ES fire 2x for a single event is odd. And creating a local variable just to retain what menu selection the user made from the "Menu User Event" state - so it can be read by the "ShortCut Activation" event is wasteful of memory, especially when you have more than a few controls.

The fact that the average programmer cannot figure this out is an indication the implemenation is a bit off.

Also, the "ShortCut Activation" Event fires BEFORE the "MenuUser" Event so it out of synch.  Meaning you create the menu BEFORE it checks exactly what the user selected?.

"Why make something difficult, when you can make it impossible..."

- J.Hamilton

[tst]

I really don't understand your problem, nor why you bring it up in an old thread, but here are some comments:

1. I don't know if the average programmer understands the implementation or not. Don't think that your own experience necessarily reflects that of many others.
2. Creating local variables of simple controls (or holding the data in other ways) may "waste" memory, but the impact is so minimal that it can be safely ignored. If you have memory allocation problems, the solution will not come from getting rid of that.
3. Of course the activation event fires before the selection event. The menu is created with the activation event (usually a right click), which is why you get the reference to it there, and is destroyed when the user makes a selection from the menu. Maybe you misunderstood what the events are?

[MrJackHamilton]

These are new threads for everyone who discovers them for the first time!. I appreciate seeing a solution to any thread old or new.

I would agree on different experiences. I've been coding in LabVIEW for 26 years and spent lots to time fixing others code. I've seen assumptions or lack thereof, on using local vars, and FP references, not understanding 'inplaceness' taken to the extreme and then hear complaints about how 'inefficient' LabVIEW is. I open the diagram and there are 20 instances of a local variable for nearly each FP control.

This concern was expressed by another who posted on this thread. I really don't write simple little LV programs anymore, I write big complex ones. So a seemingly simple 'just throw some more local vars on it' don't scale well for all applcations.

NI should strive to make their implementation as lean as possible. As now computers are scaling down now to hand-held tables and devices running on ARM processors. Which don't handle bloat code well.

It's not a nice day when you realise that these minor issues when scaled up can bring your code to a halt. You have to start rethinking, I just don't code that way anymore. I code as if it's going to run on the least performance processor.

So please respect others perspective as I do yours.

Keep wiring! Regards

J.Hamilton

[tst]

I respect other people opinions just fine. I just don't understand the problem.

As for architecture, designing for efficiency is certainly desirable, but you have to know where and when things will really have an impact. As I said before, if you have memory problems, the solution will not come from getting rid of a few simple memory allocations, but I'm sure you already know that.