LabVIEW Real-Time Idea Exchange

About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

Don't Break VIs with Menu Reference Wires

Status: New

Currently a VI running in a Real Time environment does not support run time menus.  I understand the restriction, but what I find odd is VIs that have the menu reference wire cannot compile for RT targets.  This may seem like no big deal, because why would you have a menu reference wire, but not use it?  But I have come to find two examples that make RT code a bit more difficult due to this issue.


If I have a polymorphic VI, and one of the polymorphic types has a menu reference terminal, then I can't use that polymorphic VI in an RT VI, even if the instance that is being used doesn't use the menu reference.  One work around for this is to wrap the entire VI that does use the menu reference (terminals and all) in a conditional disable structure so that it does nothing on RT.


Another issue comes in the form of templates.  I have various temples to get code started, and most of it can run on RT or other targets without any need to change the code, just place conditional disable structures where needed.  But I found one issue where I can't have an event structure on RT, that has the Shortcut Menu Activation? event, because it generates a menu reference wire. Ideally this event just can't be generated on RT, so the compiler would know to not include it, and it would allow the VI to run on RT.  Same for polymorphic VIs that have a menu reference in one of its instances.


A better solution might be to lift all restrictions of using the menu reference wire on RT, and just assume that using the menu reference on RT does nothing, like a No-Op.  Optionally an error could be generated if one of the menu reference functions are used, but for the sake of simplicity I'm not sure that is needed.  What I'm really looking for, is a way to allow VIs to run on RT, that have menu reference wires types, but aren't used.  Note the VI below which can't run on RT and the reason given is that the menu reference can't be used on RT, but it isn't being used, it is just wired to a disabled case.


Active Participant



By the way:
The menu refs do not break the VIs if the RT target supports a GUI (like cRIO-9030 for example), but then unfortunately the GUI does not support actually displaying the menus. So if you actually want to use menus you would still be out of luck.


It is such a shame, if menus were supported it would be easy peasy to port applications with user interfaces to RTSmiley Sad I was hoping for a change on this in LV2016. I have not actually checked in 2016 yet, but from the idea status here on the idea exchange it looks like it is still an issue.

Proven Zealot

I absolutely kudo'd your idea because I thought that already existed.  I haven't received my hardware yet but I asked someone at NI during an NI Week presentation on the UI development on this hardware and asked if run time menus were supported and they said yes.  Maybe they misunderstood my question, or maybe it was added in 2016.