Menu Separator Oddity

[CoastalMaineBird]

LV2013.1, Win7

I'm an old hand at LabVIEW, but new to using run-time menus.

I have a project with several windows, and I want a WINDOWS menu in each window.

I am early in development, and I'm still adding new windows.

Rather than duplicate the list of windows in each RTM, I have code to add it at ACTIVATION time:

All the different windows call this code at ACTIVATE? time.

So, when I add a new window, I add the name and tag to this list, and everybody gets it.

In most places in my project, the RTM has the WINDOW item in the menu bar, and there is nothing under it.

In those cases this works fine.  By running the above code, the WINDOW menu shows up with CLOSE as the first item, a separator, then CONFIG, etc....

However, there is one case where I want additional items in the menu before the standard ones.

In that one case, the RTM looks like this:  Note that it ends with a separator.

When I run it, that separator at the end SHOULD appear before the CLOSE item, but instead it disappears:

The separator from the code is there (AFTER the CLOSE), but the one from the RTM is not ! 

Why not ?

If I add a dummy item after the separator in the RTM:

, then it works as expected:

So, apparently, there is some rule that an RTM cannot end with a separator. Except that I can open the RTM up again and the separator is still there, it's not like LV deletes it.

My point is that I want the separator there, if it's NOT an empty menu to start with, but if it IS an empty menu, then I DON'T want to start with a separator.

Is this another case of LabVIEW trying to be "helpful" because it knows I made a "mistake", or something else I am missing?

I can change the code to detect the empty menu and decide for myself, I suppose, but why doesn't LV do what I ask?

[CoastalMaineBird]

At ACTIVATE? time, if I check for the existence of a separator tag in the menu (before adding anything), then it tells me there isn't one (error 1162 - no such tag), if the separator is the last item in the RTM.

[mikeporter]

Yes, LabVIEW can be very "helpful" 😇 at times.

It looks like this may be a limitation of the way it handles the separator. If you want to add stuff on to the end of an existing menu like this, you may need to rebuild the whole menu. To tell the truth, I have never tried this exact thing. I sometimes add entire menus as subpanels change, but in terms of the basic menus that are always there I just encapsulate it all in a subVI that I call when a screen opens. These VIs can contain static menu definitions or build them dynamically.

Can you modify the menu as the new information is added and not wait for activation? I do that as well for operations like enabling or disabling thing, but it should work for this as well.

One place where I do build menus on activation is with custom menus for controls -- but they tend to be much smaller.

Mike...

[ben64]

Played just a bit with RTM but here is something you can try:

The Insert Menu Items has a after Item input at the bottom. You can try setting this input to app_separator when inserting your new menu items. I confirm that the separator is not showing when it is the last menu item.

Ben64

[rolfk · Accepted solution]

The LabVIEW RTM handler removes trailing seperators in a menu on load as that really makes visually not much sense. So a workaround would be to query the menuWindow menu for elements and if there is at least one ("submenu tags" array being not empty), append an extra seperator first.

[CoastalMaineBird]

The LabVIEW RTM handler removes trailing seperators in a menu on load as that really makes visually not much sense.

--- I can agree with that.  I would argue that it's not LV's job to "correct" me, but that seems to be it.

After all, if I mistakenly leave a separator at the end, then it ought to look bad the first time I try it, and I'll go fix it.

I don't need a dang nanny.

So a workaround would be to query the menuWindow menu for elements and if there is at least one ("submenu tags" array being not empty), append an extra seperator first.

Yes, I was just now experimenting with that.  The SUBMENU TAGS array is only empty the first time I pop up the menu. After I add the items, the next ACTIVATE? time, it shows I have 16 items. I was originally thinking that the menu would start from scratch every time, but no, that's why I have to qualify it with "is the CLOSE item already there?".  If I don't, then every activation just appends and I get multiple copies of everything.

So, I guess I need to qualify the code with:

   Is CLOSE tag already there?

       Yes - do nothing (menu already set)

        no - is menu empty now?

             -  if no, add SEPARATOR, if yes, don't

             - add window items.

[CoastalMaineBird]

You can try setting this input to app_separator when inserting your new menu items.

That doesn't work, because the separator item doesn't exist.

If I look for a  separator, I get error 1162.

If I count the items, I get 4, not 5.

The separator has been removed before it gets to my code.

[CoastalMaineBird]

Can you modify the menu as the new information is added and not wait for activation?

Well, the addition of new windows is at development time, not run time.  That makes the menu static, not really dynamic.

The only reason I am doing it in code is so that I have ONE place to add an item to the list, rather than 5-6 RTM places.

But given that the menu seems persistent (that's news to me, but even after closing the window, the next reopen has the menu with any additions I made last time), the proper place would be in a once-only section, where the window first appears.

[CoastalMaineBird]

So, here's the fix I used, and thanks to everybody who responded.

1... Remove the check for "is the CLOSE item already there?".  The reason I put it there was that without it, I got two copies the second time, three copies the third, etc.

   That should have been a clue that I was doing this in the wrong place, but it finally sunk in.  

2... Do NOT call this code in the ACTIVATE? event.  I was thinking that it was starting from scratch every time (like a pop-up control menu does), but it doesn't.

3... Call the code ONCE from a once-only INIT place, for each window.

And in every window's INIT section (once-only), call the above code with a reference to the current VI's menu:

Thanks again to everybody, and you all have my permission to take the rest of the week off.

😉

[rolfk]

The menu stays persistent only as long as the VI stays in memory. Loading the RTM menu is a load time activity not a VI activation activity, so as long as the GUI window stays in memory (by being referenced as subVI or by an open VI reference) it keeps its menu.