Jump to content

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


vmwhere

Recommended Posts

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 by vmwhere
Link to comment

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

Link to comment

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

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.