How can I develop a ring-control with sub-menus?

[DFGray]

If you want generic submenus in LabVIEW, you will, unfortunately, have to provide them yourself.  The easiest way to do this is to launch another VI containing the menu.  I wrote some experimental code to do this many years ago.  I have attached it.  Hopefully it will prove useful.  There is probably a better implementation available now, however.  Let me know if you have questions.

[tst]

Damien, any specific problem with the native run-time menus for controls, accessible through the Advanced context menu? They've been around since at least 8.2.

[NIquist]

Hey tst,

This is a very cool feature that I was unaware of.  Thanks!

I see how when you create a 'user' rtm for the control, you have new options in an event structure to execute the control's rtm items and even access to the control's rtm referenece in the 'Shortcut Menu Activation' case.  But, I can't figure out how to use the menu VIs outside of the event structure.  How do you get a reference to the control's rtm like the one available in the menu palette for the 'Current VI's Menu'?

Tnx,

K

[tst]

---

@NIquist wrote:

How do you get a reference to the control's rtm like the one available in the menu palette for the 'Current VI's Menu'?

---

Who said you can?

I never used this feature, but if the activation event gives you the reference, that should be enough, as the menu doesn't actually exist before that point in time. I'm assuming the activation event allows you to modify the menu before it's actually displayed. This may not be the ideal situation (it forces you to put code in one specific place), but unless you can find some property or something which returns the reference, I guess that's what you're stuck with.

[NIquist]

Yeah, I already looked through the property nodes and found nothing.  You're right it's not a big deal to use the events but it would be more convenient to be able to pass a simple reference(s) to a control's rtm into, say, an action engine that handled updating all your controls rtm's. 

[DFGray]

tst, there is no problem with the native run-time menus.  I had simply forgotten about them, since it has been a long time since I used them.  They are also the reason the VIs I posted above did not get developed much more.  Unfortunately, they can be more than a bit counterintuitive to get working, if you want to do more than static assignment.  You do have complete ability to dynamically specify them before they are shown using the standard LabVIEW menu VIs if you intercept the mouse events in the event structure.

If you need more information on using these menus, consult the LabVIEW help.  It is somewhat poor on this subject in LabVIEW 8.2, but has been improved a lot since then.  The online LabVIEW 2010 help may be more useful.

[D60]

If any solution is ready it could be greatfull if an example code will be provided!

Thank you very much!

[NIquist]

---

@Durnek wrote:

If any solution is ready it could be greatfull if an example code will be provided!

Thank you very much!

---

You already have the shipping examples.  (e.g.)...

C:\Program Files\National Instruments\LabVIEW 2010\examples\general\Run-TimeShortcutMenu.llb\Run-Time Shortcut Menus.vi

[m3rl3n]

Kind of a resurrection of this topic.  My problem is slightly different tho.

My company has a core set of drivers developed for the variety of test equipment that we use. All of these are written in C# <shudder> ;). I am writing LabVIEW wrappers to the .NET classes that will allow us to utilize these alreay developed (and maintained) drivers to make using LabVIEW in our architecture a lot easier.

The one that I am working on right now is the driver for our spectrum analyzers. I am making one VI that has a case structure with invoke nodes to access the various methods in the .NET classes.

The problem is that that the ring control that I'm using is getting very long. For example, just the display commands # in the 70s. Then there are the methods for Markers, NoiseFigure, PowerMeter, etc. What would be nice is a flyout menu that at the top level would show General, Display, Marker, Markers, NoiseFigure, etc, then under each of those the methods that are available...

The problem is that this wrapper is only available to the programmer, not the user, so when the programmer is selecting which method they want to use, the VI is not running making a rtm menu an unacceptable choice.

Any ideas?

Dan

[tst]

Perhaps I'm misunderstanding what you want to do, but why are you creating a single VI for all the methods? It would make a lot more sense to create a single VI for each method.

Since you have a lot, it might be worth it for you to script these VIs. A quick look at the properties for an invoke node shows that it has a property for all the methods it supports as well for setting the current method and getting the input and output terminals. You should probably be able to use that to write code which will generate all the wrapper VIs.