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

[vmwhere]

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 and load a new .rtm for a *control*

Thanks in advance for any thoughts. I'm working in LabVIEW 8.6 for this particular project.

VM

Edited February 18, 2011 by vmwhere

[jgcode]

Yes, AFAIK that is common behavior.

Why don't you write code that flattens the menu data to disk so it's persistent, then read it back on startup (or whatever)??

[vmwhere]

Yes, AFAIK that is common behavior.

Why don't you write code that flattens the menu data to disk so it's persistent, then read it back on startup (or whatever)??

Hey, thanks for the quick reply! I think I may not have articulated the issue I'm seeing very clearly. Let me try again here.

Basically this is a performance desire... I want to avoid having to generate the menu dynamically on *every* right click to the control.

No problems managing the menu data and reading it in when the app initializes.

Currently I have the code which does this and generates the new menu items dynamically, and that's running each time the menu is activated (on right-click).

What I was *hoping* for was a way to update the menu *one time*, and have *all* subsequent menu activations keep the items added that first time?

Thanks again for the help!

VM

[tushar]

may be you can put it in NI LabVIEW idea exchange...

I think that is the better place for this.

[jgcode]

It was presented as a question rather than an idea. I agree - the IE is the best place.

[i2dx]

Currently I have the code which does this and generates the new menu items dynamically, and that's running each time the menu is activated (on right-click).

I stumbled uppon this issue, too, some time ago, and finally I kept the code, that generated the menus dynamically. If you don't use H U G E right click menus, there is no recognizable performance loss. I've tested that with 40-50 menu items (which were created dynamically themselfes, depending on the item you clicked on) and did not recognize any delay

gl&hf

cb

[vmwhere]

I stumbled uppon this issue, too, some time ago, and finally I kept the code, that generated the menus dynamically. If you don't use H U G E right click menus, there is no recognizable performance loss. I've tested that with 40-50 menu items (which were created dynamically themselfes, depending on the item you clicked on) and did not recognize any delay

gl&hf

cb

Thanks everyone for chiming in - this was great!

Performance Note

As an addition to the performance note, I also experimented to see when the dynamic menu generation might become prohibitive from a performance/user experience perspective.

This will definitely depend on the machine running the app, but even on an old, modest Windows XP machine I observed reasonable performance:

• up to 1000 new menu items - virtually unnoticeable.
• 2000 - noticeable but tolerable
• 5000 - noticeable, possibly tolerable if absolutely necessary
• 10000 - prohibitive in my opinion (delay over 1 sec)

Thanks again!

VM

[jgcode]

Having a user navigate through 1000-5000 menu items in a right click menu seems prohibitive from a user-experience??

[i2dx]

Having a user navigate through 1000-5000 menu items in a right click menu seems prohibitive from a user-experience??

hmm, maybe Jim would love such right-click-menus? :D

Edited February 20, 2011 by i2dx

[jgcode]

hmm, maybe Jim would love such right-click-menus? :D

lol

[vmwhere]

Having a user navigate through 1000-5000 menu items in a right click menu seems prohibitive from a user-experience??

Hi again,

That's a good thought/consideration. I agree having many items may become prohibitive, especially with *flatter* menus.

However, it doesn't take *that* many items for, say, a 4 level menu to balloon to near 1000 elements.

Consider a 4-level menu. Suppose each level has 6 options. One example might be 6 locations, 6 labs per location, 6 instruments per lab, 6 options per instrument.

That's nearly 1300 *menu items* from LabVIEW's perspective (total item tags, not simply the leaf entries), and isn't *too* crazy =)

Hence, considering LabVIEW's ability to dynamically populate ~1000s of menu items can be reasonable.

Thanks again for the great thoughts all around on this!

VM

[Aristos Queue]

For the record, all of the built-in items that you see when you pop up on something in LabVIEW are dynamically built every time you right click. Performance hasn't been an issue there, and some of our menus (say, the "Select Class" menu when you pop up on a VI Server refnum control) are pretty intense -- both long and deeply nested.

[vmwhere]

For the record, all of the built-in items that you see when you pop up on something in LabVIEW are dynamically built every time you right click. Performance hasn't been an issue there, and some of our menus (say, the "Select Class" menu when you pop up on a VI Server refnum control) are pretty intense -- both long and deeply nested.

Ah, very cool thanks for chiming in with that! I won't feel too guilty then ;-)

Best,

VM

[jgcode]

...(say, the "Select Class" menu when you pop up on a VI Server refnum control) are pretty intense -- both long and deeply nested...

Thank goodness for Quick Drop's VI Server Rename Plugin I say