Preserving run time menus

The problem is that applications do not preserve custom run time menus applied to graphs or controls once the executable is run on another machine, or an installation is built and installed on another machine. I have tried advice from this board about saving .rtm to alternate llb's, to the same destination/support, opening from within development vi and saving to the same path as development vi.
Surely the concept that you want to define a custom menu for a control and have your customer see this one when he installs is not a foreign concept within Labview. How can this be done?

Here's how the two workarounds would play out in this situation:
In the first workaround, you'd have to open the run-time menu editor for each control individually and choose to save the run-time menu to the control instead of the file. I don't think this is a very risky procedure, but it would be tedious. One thing to keep in mind is that in order to get the prompt to save the menu to the control or to a file, you'll need to make some small change to the menu. For instance, you could press the add button to add a temporary item and then the delete button to delete it. Then when you close the menu you'll see the option to save the menu to a control. I suppose this step is the only real risk in the process
In the second workaround, you'd have to create 3 or 4 new event structure cases, one for each of the different run-time menus you want to display. Then you'd have to register each separate event for all the controls that correspond to that particular menu. This seems a little more risky, because the new code might induce bugs into your system, or you might forget to register the event for a control, or register the wrong event for a control.
Jarrod S.
National Instruments

Similar Messages

  • Combining LVOOP DVR with Asynchronous Dynamic Dispatch and Preserve Run-Time Class

    OK, the title sounds like a cornucopia of LVOOP terms.  But there's a reason.  This is in a way an extension of THIS thread.
    What I'm doing recently is creating a LVOOP approach to loading Completely Asynchronous UI elements into subpanels.  This I have combined with a global repository for the objects (which are essentially singletons with a UI functionality) which are shared via DVR, thus eliminating a lot of synchronisation headaches).
    This means that I can ahve a universal framework for launching the UI elements into a subpanel.  The changes made on the Object there are automatically reflected in the global repository.
    So far so good.
    What I don't like too much is a combination of two seemingly awkward code constructs I need in order to keep things running.
    Weird construct 1:
    I have defined a "Launch UI" function in my parent class which is Dynamic Dispatch (Allowing each object to take care of launching its own UI).  This takes a parent object DVR as a second input which I make sure is of the exact same type as the object type being invoked by using the code shown below.  The ACTUAL Type of both inputs to the launch VI within the IPE are identical.  This is guaranteed because I require each new class to override this function.
    Here I pass the DVR from outside the IPE to the "Launch" VI but the Object obtained within the IPE retains information required for DD thus ensuring that the VI called for launching the UI is identical to the ACTUAL object type in the DVR.  This works OK and by placing this weird construct WITHIN the parent class, abuse is minimised, it works fine and seems to have no major side-effects.
    So now we have a VI running asynchronously in the background which belongs to a specific object but has a DVR which it *thinks* is of a Parent Type but, because of the steps taken earlier, is actually of the same type as the object itself.
    In order to make use of the functionality defined in this actual object type, I need to continuously re-interpret the Object within the IPE as shown below.  Otherwise only the Parent functionality is available.
    If I am accessing only methods of the parent class, then the Preserve functionality is not needed.
    Is there a more elegant way to do this?  I find the net result of this code and type-juggling to be really useful and much easier to manage than the non-DVR route since the synchronisation issues disappear.  By making the IPE usage near-atomic we remove the chances of deadlock.
    All editing done in the UI of the asynchronous VI is reflected automatically in any subsequent usage of the DVR.  Even if the DVRs are not shared between VIs, this makes (for me) the headache of synchronisation easier.  If you start expanding this beyond the limits of a single VI, the benefits in Synchronisation become really huge.  You can even have multiple UI objects operating on the same data in the background without extra synchronisation needs.  The only synchronisation required is a global "Data updated" for the object in question whereby the UI elements simply update their indicators and controls from the DVR again.  This is trivial.
    Thus I am convinced that the net result of this is very beneficial.
    My question is if there's a better, safer or more "official" way to do this?
    I was about to start a new Idea for combining the "Preserve Run time Class" and the DVR Terminal of the IPE so that the casting is done automatically.  We could then have a double input to the IPE, the DVR (of base type) plus the ACTUAL Type of the object but of course returning an error if the types are incompatible.  It would be like an "Imposter" DVR input for the IPE which allows a re-interpretation of the object type.
    Would all of this go away if we allowed Dynamic Dispatch to work with DVRs?  Probably.
    Shane
    Say hello to my little friend.
    RFC 2323 FHE-Compliant
    Solved!
    Go to Solution.

    You guys rock!
    I didn't even think of casting the DVR like that.  Kinds stupid of me but I never would have thought it would work.  Cool.
    Also, Yeah, the limitation of no IPE in the Launch VI was one I spotted quite early on.  this is why my Launch VI also doesn't accept more data than is absolutely neccessara because a DVR access in that VI will of course cause a lockup.  I have the system so far now that I can have a SINGLE Launch VI (Which is NOT overridden, so the limitation refers to only a single VI now which is certainly better.
    So again guys, thanks for helping out an old newbie.  I've been around for quite a while, have made many posts but I love the way I just keep learning from others in the Forum.  This is just why I absolutely LOVE it here. 
    Shane.
    Say hello to my little friend.
    RFC 2323 FHE-Compliant

  • Check marks on custom run-time menus

    Is there a simple way to add a check mark for currently selected item on custom run-time menus?  
    The only method I have found is to fire off of the "Shortcut Menu Activation?" event, grab the menu reference, and basically recreate the shortcut menu with the proper check marks based on boolean values.  This method just seems ... cumbersome for something that should (in theory) be fairly common. I can't help but think there is a better solution.
    Thanks!
    Solved!
    Go to Solution.

    Hi Bown,
    you can assign custom menus with the menu editor to your controls/VIs. They will be saved as rtm file.
    Using the known tag names of such custom menus you can set the checkmark for your tags without rebuilding the menu on activation each time…
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • Custom run-time menus within dynamically called sub-VIs?

    How do you use custom run-time menus within sub-VIs that have been dynamically called? I'm using Labview 6.02.

    Since you say within subVIs, I am assuming that you have the subVIs open their front panels when called. Each subVI must have the RTM defined when the subVI is created. You can use the same RTM for each one (use the open function in the menu editor).
    If necessary, you can dynamically add and remove menu items using the Application Control->Menu functions. I have some subVIs that add items to the main RTM when they are loaded and remove the items when they finish.
    Rob

  • Creating customized run-time menus

    I am trying to create a customized run-time menu when I right click on a tree control. I can disable the existing run-time/pop-up menu but would like the ability to use a different customized menu.
    I can simulate a run-time menu by using creating a VI that functions in a manner similar to the menu but would prefer the ability to create and process and customized run-time/pop-up/floating menu.
    The menu is always of a fixed size with all items enabled. I do not need the ability to modify this menu within the application.

    There is an LTR article by David Ritter called "Contextual Pop-Up Menu Programming" that shows a method similar to yours. It is well worth a look.
    -Jim

  • Run-time menus and save with control

    I created a custom shortcut menu (on an XY graph) and saved it by selecting "save with control". This worked fine while I was running LabVIEW but did not work in the executable version that I created. The label of my XY graph was something like "X/Y GRAPH". I guessed that LabVIEW was trying to save my shortcut menu by using the string "X/Y GRAPH" and that the "/" was causing the problem. I changed the label to "XY GRAPH" and everything now works fine.  Does this count as a bug? Do widget labels need to use legal filename characters if I am going to create custom shortcut menus?

    Hi Oyester,
    I have reproduced your situation and this does not count as a bug--the slash counts as a special character and the filenames have to be alphanumeric. I hope that answers your question.
    Ipshita C.
    National Instruments
    Applications Engineer

  • Shortcut run-time menus and ActiveX

    I'm working on a Labview video player with four instances of VLC embedded in it, as ActiveX controls.  After some help from the forum, it runs very well, but I would like to implement custom right-click menu's for the ActiveX windows.  Currently, nothing happens when the user right-clicks on the ActiveX control.  I've tried enabling the shortcut menu, editing the menu, etc, and nothing worked.  I've tried overlaying another transparent control over top of the ActiveX window, but the ActiveX control seems to want to be on top no matter what I do.  Any ideas?
    Running LV 8.6.1f

    i tried the same with windows media player since i dont have VLC.. Did you use the shortcut menu activation property? see the attched vi
    Regards
    Guru (CLA)
    Attachments:
    1.vi ‏10 KB

  • Application's run-time shortcut menus don't work on local drive.

    The run-time menus in my application don't work, unless I run the application from the location where it is built.  This project has an application build specification, and an installer build specification.  The installer specification, copies the app to the local drive.  But the run-time shortcut menus do not work when the app runs.  Nothing happens when I right click on the control.  However if I run the same app from the network drive, where the application build spec builds it, it runs fine.  When I have the application build spec build the app directly to the local drive, it works fine.  The exe, ini and aliase files are identical.  Why does this app run differently depending on which drive it's on?  How can I fix it so the run-time shortcut menus work on the target machine?  Any ideas?

    Hello, I believe that when you create a custom run-time menu it gets saved to a file.  My guess is that you are not including this file as part of the build specification for the application.  The file likely exists in the build directory but does not on the target directory which is why it no longer works.  If that does not fix the problem, let me know and I will see if I can figure something else out.
    Regards,
    Burt S

  • Custom Run-Time Menu Not Found in User.lib

    Our Instrument Run-Time Menus are getting lost.
    This is because we have some computers that are 32 bit and the code is located at
    C:\Program Files\National Instruments\LabVIEW 2011\user.lib\InstrumentDrivers
    Other computers are 64 bit and the code is located at
    C:\Program Files (x86)\National Instruments\LabVIEW 2011\user.lib\InstrumentDrivers
    The directories are thus slightly different because of how Windows treats the location of 32bit LabVIEW running on a 64 bit machine.
    Does anybody have an easy work around?

    I'm confused by "lost".  Do you mean when you build the path to your custom menu within your vi or are running some executable?  Is this code you have written?  If so, then maybe a simple check when initializing the paths might work.
    If it is as simple as just having to decide between those two directories, then I would just check to see if the win64 bit directory exist, using "file directory info" vi.  If it doesn't' exist you should get an error, then check to see if the other path exists, it should hopefully, and use that.
    Not sure if this is what you need.

  • Problems with executing customized Run-Time menu from a sub-vi imported from the main vi.

    I am having trouble executing Run-Time menu from the sub-vi.
    Currently my main vi program, which is the first thing that I open up to acquire data from different sources (i.e. dll’s, scanners etc.) opens up a number of sub-vi’s.
    I have created several sub-vi’s, which are opened from the main vi’s customized Run-Time menu that I have created (i.e. dsp file). I am using the open panel.vi to open other sub-vi’s. I don’t have any problems opening any number of sub-vi’s through the main vi’s menu.
    I would also like to have the option to open other sub-vi’s from any sub-vi’s menu. I succeeded in exporting the Run-Time m
    enu from the main vi to the sub-vi using the property node properties however nothing happens (I hear a beeping sound) when I click on the sub-vi’s menu. I don’t know what I am doing wrong. I would really appreciate it if someone can attach a sample code using Run-Time menus on sub-vi’s imported from the main vi.
    Thanks
    Nish

    I don't actually have any VIs like this. It might be easier to take the menu and just add it to the VI during development. Then it will always be there. It might be easier than doing this with Property Nodes.
    J.R. Allen

  • Switching between different run-time menu programati​cally

    Hi All
     I am planning to build a Bilingual program…….am just doing trial and errors in changing all captions and run-time menu s programmatically with a single button click……….Here my logic is working fine for all captions and graphs also…………..but I could not change the run-time menu……….i am unable to switch between different run-time menus……………
    Here I am sending the program am working on………..please have a look on this, and suggest me something………….hope my problem get resolved.
    Thanks
    Anil Punnam
    Attachments:
    Caption_program.ZIP ‏31 KB

    Hi Anil,
    I'm guessing you're using 7.1?  When I first ran your program in 8.0, it worked perfectly and switched back and forth perfectly.  However, I tried it in 7.1 and saw some bad behavior.  The customer run time menu was not updated in the menu bar.  It looks to me like the run time menu is changing, but the front panel is not updating.  After pressing one of your front panel buttons to change the run-time menu back and forth, if you click on the file menu it should update, although this can lead to some funny looking menus since "affiche" is longer than "file" and you can still see the remnants of the old menu.  Try this and let me know if this is indeed the behavior you are seeing (check out the attached pic).  I thinkt hat R&D already had a report on this, and that is why it is fixed in 8.0.
    Megan B.
    National Instruments
    Attachments:
    RTM.JPG ‏34 KB

  • Is it possible to preserve dynamic run-time shortcut menu updates for a control?

    Hello all,
    I have a question about getting control run-time shortcut menus to persist after adding new items.  I am hopeful that I'm simply missing something simple here.
    Known Information
    I understand the use of the "Shortcut Menu Activation?" event (for the control of interest) which provides the relevant control's menu reference for use with the menu VIs.  No problems there.
    Problem
    I start with a control which has an .rtm file assigned as its run-time shortcut menu.  
    I then generate new items dynamically using the event/menu mechanism noted above.  
    The problem is that there doesn't seem to be a way to *preserve* those newly added items (ie. I have to re-create the new items everytime the menu is *activated*).
    What I observe is that, unless I add all the items every time the right-click event occurs (in the "Shortcut Menu Activation?" event case), it defaults back to the original .rtm menu state.
    Question
    Does anyone know how to either:
    get dynamically added menu items to "stick"
    perhaps dynamically create (new) and load an .rtm for a *control*
    Thanks in advance for any thoughts.  I'm working in LabVIEW 8.6 for this particular project.
    VM

    Looking at the second post link, it seems like you are trying to populate 10,000+ shortcut items on the Shortcut Menu for the control. I'm guessing these are tiered, since I don't think all of them would fit on the screen. If they are tiered, have you tried populating only the top level short cuts, and then populating more as the user navigates down the tree?
    - Regards,
    Beutlich

  • Check marks or dynamic items for run-time shortcut menus

    Labview version: 8.0
    I'd like to create a run-time shortcut menu for my Xcontrol, that would
    allow user to toggle between two states of the control. Is it possible
    to either
    1) dynamically apply check marks to run-time shortcut menus or
    2) dynamically modify the run-time shortcut menu content
    Tomi
    Tomi Maila

    Hi Tomi,
    Great question.  Yes, you can do what you want with run-time shortcut menus in LabVIEW 8.0.  If you want to dynamically modify the menu content, you have to do it in the "Shortcut Menu Activation?" event in the facade VI of the XControl.  In the event data for this event is a parameter called "MenuRef" which works with the same menu primitives that have been around since LabVIEW 5 for editing the menu bar at run-time. 
    With these primitives, you can add/delete/modify menu items to the shortcut menu.  The items that are already in the MenuRef when this event case executes are always the ones that are statically defined, either by LabVIEW or by customizing them.  You do not have control over the state of the items that LabVIEW adds, but you can remove them and add ones with the same text (just with a different tag).  In your case, you would probably want to use the Insert Menu Item primitive to add an item such as "Toggle State".  Give it a tag such as "USER_TOGGLE_STATE".  Then you'll want to use the Set Menu Item Info primitive to set the checkmark for that item based on the state of the XControl.
    Then, you'll need to add an event case for the "Shortcut Menu Selection (User)" event so you can handle the item being selected.  Wire the Item Tag parameter from the event data to a case structure and add a case to look for "USER_TOGGLE_STATE".  And in that case, toggle the state of your XControl.  That's all you need to do!
    The Dual Mode Thermomter shipping example in <LabVIEW 8.0>\examples\general\xcontrols\Dual Mode Thermometer\Simple Dual Mode Thermometer XControl.lvproj is a simple example of how you can modify the menu and respond to the items selected.  It's a little different than what you want to do, but it might help you to look at it.
    Good luck!  Let me know if you have questions.
    Robbie

  • Question about Run-Time Shortcut Menus example

    I am looking at the Run-Time Shortcut Menus.vi that ships with LabVIEW2011. There is an event case "Test List":Mouse Down that does nothing but generate a Val(Sgnl) event for the "Test List" control if the right mouse button was pressed. There is no value change event for that control.
    Is there an obscure reason to do that? One thing I have learned about many of the examples is not to strictly use them as examples.
    =====================
    LabVIEW 2012
    Solved!
    Go to Solution.

    Nevermind - I found the obscure reason. Even though there is not a value change event, generating the value change event is required to change the value on right-click.
    At least NI could have documented this in the example
    =====================
    LabVIEW 2012

  • Run-Time Shortcut Menus

    Hi,
         How can i create Run Time Shortcut menu
    with tick mark?. like here i am attached the file.
    Thanks in
    Advance.
    Sivaraj M S
    Sivaraj M.S
    CLD
    Attachments:
    bb7a9f541545.gif ‏11 KB

    Hi Siva,
    are you talking about the checkmark?
    Read the help for "Set Menu Item Info" function and you will notice the "checked" input
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

Maybe you are looking for