From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Programmatically show and hide menu bar items - aka switch between to menus at runtime

Hello,

 

I'm currently working on a more complex LabVIEW-Project and would like to programmatically show and hide items in the menu bar. Here is a mock-up of what I want to achieve in LabVIEW 2012:

Mock-Up-2.png

I used the example "Dynamic Insert Demo.vi" as a base. For the "expert user" I want to display the menu on the left hand side. As Default onle the one on the right Hand side should be visible.

 

I know I can use "Delete Menu Items.vi" and "Insert Menu Items.vi" to delete and add menu points and menus. I would like the menu points to reappear at the correct position and not at the end. Imho that would mean hassle with strings or arrays of strings since my menu points aren't sorted alphabetically. Same for the menu point tags.

 

Is there really no easier way or more elegant way? Similar to "Set Menu Item Info.vi" for disabling menu points? Having two seperate *.rtm files could also work, but I don't know if it is possible to switch at run time in an exe-build. 

0 Kudos
Message 1 of 6
(3,205 Views)

I guess delete\insert is the only way.

 

But... You can set the "after item" tag. That would insert them in the correct place.

 

And of course, instead of delete\insert , you can enable\disable the items. But I get that's not always desireable.

Message 2 of 6
(3,168 Views)

Thank you very much for hinting the "after item" tag.

 

I somehow overlooked it or didn't understand that it also works with tags(strings). That will make my endeavor much simpler. I was trapped in the mindset, that this vi could only add Menu Items at the end.

It may take a few days, but once I get back to that project I'll post my solution here.

 

Sometimes you can't see the forest for the trees, or connectors in this case. 😉

 

P.S.

Currently I sparsely enable/disable Menu Items, but that won't help to unclutter my menu. Imho it gets even more cluttered, if 10%-30% of the menu points are disabled at random.

0 Kudos
Message 3 of 6
(3,147 Views)

@Peter-2012 wrote:

 

P.S.

Currently I sparsely enable/disable Menu Items, but that won't help to unclutter my menu. Imho it gets even more cluttered, if 10%-30% of the menu points are disabled at random.


It's in general good practice to disable (not hide) menu items, so users won't feel they're working with a moving target. Extra items when you log in is a different situation, though. Perfectly justified situation to hide the items then.

0 Kudos
Message 4 of 6
(3,133 Views)

> so users won't feel they're working with a moving target.

I attached a mock-up of the "Load File" menu from my "File Converter". The easiest solution would be to just scrap the features, because currently nobody uses them. But I'm to proud for that. So I will just hide them to clean up the menu and make them visible in an "expert mode". Here the comparison between disabled (left hand side) and my idea (right hand side):

 Mock-Up-3.png

 

Btw, the GUI language is currently German, so the names are even more cumbersome than in this example.

 

I'm quite new in programming GUIs who are mainly not used by me. So if there are guides on this topic out there, I would be interested in them. I searched a few weeks ago but didn't find much on LabVIEW menus. So now I'm learning by trial and error.

0 Kudos
Message 5 of 6
(3,124 Views)

What I usually do, is to make a string format that fits entire menus. And a vi to turn them into menus. Then simply edit\manage the strings, and clear and rebuild the entire menu each time.

 

Of course that depends on the situation...

 

In your situation, that might work fine. Until the item you add after is itself removed (or changed it's name). So it could become fragile... Just be aware of that. If it does turn out to be fragile, refactor before it becomes a problem.

 

0 Kudos
Message 6 of 6
(3,114 Views)