Forums Bug Reports $submenu, 'end' and empty popup

There is a problem with $submenu, if you have not returned anything to create one menu item when "end" is sent, and you use the "end" iteration to return a valid menu item, making that returned item the only menu item, it won't work, it won't get displayed.
The above code will execute /return for both "begin" but especially "1", making $submenu's next call the "end", in which case "return $1 : echo -sg cmdfrompopup $1" is returned, but is never displayed.
Change "1begin" to "begin" so that the iteration with "1" result in a valid menu item from the "/return $1 : echo -sg ..", making then the "2" iteration an empty /return, which then makes the next iteration "end". But this time, the "end" menu item shows up.

As mentioned in the help file, the begin and end items are used to indicate whether separators are used to enclose the menu. The $submenu() help file example shows you how they should be used.

Using the following help file example...

I suspect that $submenu works with the following calls as follows:

In the example code provided in this bug report, $subtest(1) returns null indicating that there are no more menu items, thus resulting in an empty menu with an end terminator value of "end : echo -sg cmdfrompopup end" - but A) it is unclear what happens when "begin" or "end" return anything other than "-" - it could provide a standard separator or do nothing or use the text as a separator; and B) it is undefined by the documentation whether a submenu is shown at all (with any separators) if there are zero menu items provided by $subtest(1) being null.

You can return anything you want when $1 equals "begin" or "end" but the practical use is to return "-" for line separators, if you want them.

If you want to ignore these iterations, thus returning nul string (implied return) then just delete those lines, or use the operator "isnum" and they will be skipped and ignored.

Your answer suggest that 'begin' and 'end' should not have been used to return a menu item other than a separator.

The help file is not clear about what you can return with 'begin' and 'end', it is only mentioned that they are send to check if the items should be enclosed in separator.
Since the help file is not saying anything about returning something else than a separator for these two and since it has always worked this way, one can only assume it is meant to work

I have already returned something else than a separator in the past, for me the behavior is expected and this is a break in compatibility.
I wrote a script for TECO which used this behavior on purpose.

The way $submenu works is unique. One of its drawback, if i may, is that when you are done with displaying your menu, you must /return an empty value, otherwise mirc will feed you with N+1. This is in conflict with using return for creating a menu item: you can't both stop $submenu and return a menu item.
It may seems trivial but this is extremely annoying when you are done and need to return a menu item.

Because of this and because $submenu can only create one menu item at a time per return, the only workaround possible is to get into this bug report mode: you must return nothing first to stop getting N+1 and then you must return your menu item for the 'end' iteration, which is how TECO found this issue.

So.. you're not done then? What stops you from returning that last menu item as N+1, and return nothing for N+2 ?

I am also a little confused by what @Wims is saying. Can you provide an example of the submenu you want to create and show code on how you think you should be able to create that submenu but currently can't?

Interrupting raccoon says: "And I'm just over here wishing there was a /popmenu [@]<menu name> [x] [y] so I can show a menu from an alias/event instead of just click/rightclick. Ie: Show a new menu from clicking a menu item. Why? Dynamically created menus that take 5 seconds to load, heavily enumerating nickname / channel / IAL relationships of a particular nickname or channel."

raccoon scurries off

I thought about this flaw in my wording yesterday but then thought it wasn't actually a flaw.

Well the difference in behavior is certainly inconsistent, if begin and end are not meant to return anything else than nothing or a '-', not only the help file should be made clearer, but the bug report is the other way around, $submenu should never allow begin and end to return a menu item, regardless if the popups menu is currently empty or not, only separator or nothing:

I have not had to do this in mSL, but in other environments the way to deal with this is to do as much processing in advance with a batch process on load and then updating using events, so that when you right click a lot of the work has already been done.