WindowMenu's flatness leads to an inability to organize the menu structure. It would be nice if selection of certain menu items, rather than returning, instead popped up another level of nested options.
windowmenu sub-menus
Posted by Fiendish on Wed 14 Apr 2010 10:11 PM — 26 posts, 98,598 views.
I would like to see something like this too.
Maybe have a + in front to make it under the item that was previous to it with a higher level.
So If I had something like this:
"|| Font || +Set font | +Increase font size | +Decrease font size | +Default Font ||| Colours | +Background Colour | +Text Colour"
It would appear like this
----
Font -> on mouseover, submenu of Set Font, Increase, etc
----
Colours -> on mouseover, submenu of Background Colour, Text etc..
----
How hard would that be to do Nick?
Bast
Maybe have a + in front to make it under the item that was previous to it with a higher level.
So If I had something like this:
"|| Font || +Set font | +Increase font size | +Decrease font size | +Default Font ||| Colours | +Background Colour | +Text Colour"
It would appear like this
----
Font -> on mouseover, submenu of Set Font, Increase, etc
----
Colours -> on mouseover, submenu of Background Colour, Text etc..
----
How hard would that be to do Nick?
Bast
I'm on holidays right now so I can't check the source code or try it out. Remind me in a few days if I don't reply again by 5th July or thereabouts.
Version 4.52 adds sub-menus.
You can nest menus by doing something like this:
Nested menus can have further nested menus.
You can nest menus by doing something like this:
Item = "Take | Drop | >Eat | With Fork | With Hands | < | >Emote | Smile | Laugh "
This would display:
Take
Drop
Eat ->
..With Fork
..With Hands
Emote ->
..Smile
..Laugh
(Where Eat and Emote are nested menus)
Nested menus can have further nested menus.
Works and looks great! Thanks Nick!
Bast
Bast
Sub-menus are great but there's a problem with them.
If you have three menu choices:
A, B and C.
Each of these three choices has a sub-menu. All those three choices have the same type of sub-menu, the choices D and E. A practical example is having a list of objects 0 .. n that you want to do either action D or E on.
Upon return, I will always receive D or E no matter if the menu-choice A, B or C was selected to get to the sub-menus. If that makes sense.
To explain it in another way:
Menu
.A
..D
..E
.B
..D
..E
.C
..D
..E
I want to know if it was a A-D, B-D or C-D choice that was made. Not simply a "D" choice. Is that possible somehow? If not, could we please have it added :)
If you have three menu choices:
A, B and C.
Each of these three choices has a sub-menu. All those three choices have the same type of sub-menu, the choices D and E. A practical example is having a list of objects 0 .. n that you want to do either action D or E on.
Upon return, I will always receive D or E no matter if the menu-choice A, B or C was selected to get to the sub-menus. If that makes sense.
To explain it in another way:
Menu
.A
..D
..E
.B
..D
..E
.C
..D
..E
I want to know if it was a A-D, B-D or C-D choice that was made. Not simply a "D" choice. Is that possible somehow? If not, could we please have it added :)
Quote:
Menu
.A
..D
..E
.B
..D
..E
.C
..D
..E
I want to know if it was a A-D, B-D or C-D choice that was made. Not simply a "D" choice. Is that possible somehow? If not, could we please have it added
Menu
.A
..D
..E
.B
..D
..E
.C
..D
..E
I want to know if it was a A-D, B-D or C-D choice that was made. Not simply a "D" choice. Is that possible somehow? If not, could we please have it added
I just recently had this problem too, and I solved it by making all of the strings unique. Like if A and B are "Sword" and "Axe" and "D" and "E" want to be "Swing" and "Drop", I made them "Swing Axe"/"Swing Sword" and "Drop Axe"/"Drop Sword". But a better solution would be to return an index as the result of a menu selection instead of a string.
Is there something wrong with quoting in the forum now? It took me like 10 tries to get this quote to work.
There is some problem with characters with the high-order bit on. Not sure what started it, but maybe when I updated the MySQL database engine. Will look into it.
Will also look into the menus, but see how I can do it without breaking backwards compatibility. If not, hopefully not too many people are using submenus right now.
Will also look into the menus, but see how I can do it without breaking backwards compatibility. If not, hopefully not too many people are using submenus right now.
Nick Gammon said:
Will also look into the menus, but see how I can do it without breaking backwards compatibility.
Will also look into the menus, but see how I can do it without breaking backwards compatibility.
Return two values like loadfile does. The current string return goes in the first one, and the index goes in the second one. That should keep compatibility with code that only expects a single return because the first gets used and the second gets tossed (I think).
An alternative might be adding a new GetInfo selector that returns the index of the most recent menu selection. No backwards compatibility problems there.
Twisol said:
An alternative might be adding a new GetInfo selector that returns the index of the most recent menu selection. No backwards compatibility problems there.
An alternative might be adding a new GetInfo selector that returns the index of the most recent menu selection. No backwards compatibility problems there.
That would be an extremely ugly use of GetInfo that violates all sorts of code design rules.
No arguments there. (Also, I meant WindowInfo, since we're taking about miniwindow menus.)
Since I want to have backwards compatibility, and don't want to add another argument, how about some special prefix, eg. "!" in front of the whole string? If present, you get an index back instead of a string (eg. 1, 2, 3).
Failing that, just another function like WindowMenuIndex or something.
Failing that, just another function like WindowMenuIndex or something.
Nick Gammon said:
Since I want to have backwards compatibility, and don't want to add another argument, how about some special prefix, eg. "!" in front of the whole string? If present, you get an index back instead of a string (eg. 1, 2, 3).
Failing that, just another function like WindowMenuIndex or something.
Since I want to have backwards compatibility, and don't want to add another argument, how about some special prefix, eg. "!" in front of the whole string? If present, you get an index back instead of a string (eg. 1, 2, 3).
Failing that, just another function like WindowMenuIndex or something.
Would a second return value as given by loadfile not satisfy the requirements?
These are not necessarily Lua functions (they use COM to be compatible with all scripting languages).
However if you were prepared for only Lua to have this second value, yes that could be done.
However if you were prepared for only Lua to have this second value, yes that could be done.
Modified in version 4.65 to return a number if the first character of the string is the "!" character. This is compatible with all scripting languages and is the simplest to implement.
Return a number? Is the number the index in the first list or the second list? Or will there be any way to get both indices?
Awesome! Thanks!
Nick Gammon said:
These are not necessarily Lua functions (they use COM to be compatible with all scripting languages).
However if you were prepared for only Lua to have this second value, yes that could be done.
These are not necessarily Lua functions (they use COM to be compatible with all scripting languages).
However if you were prepared for only Lua to have this second value, yes that could be done.
Oh I see. Yeah, that wouldn't be fair to other languages.
So what happens now if you want your menu option to start with "!"?
Well, I am just me, but I cannot really think of any good reason to start a menu item with a !. Can you?
Fiendish said:
So what happens now if you want your menu option to start with "!"?
So what happens now if you want your menu option to start with "!"?
See:
http://www.gammon.com.au/scripts/doc.php?function=WindowMenu
WindowMenu docs said:
WARNING - we reserve non alpha-numeric characters in the first position of each item for future expansion. For example, perhaps in future versions "*Equip" might be used to tick the Equip item.
WARNING - we reserve non alpha-numeric characters in the first position of each item for future expansion. For example, perhaps in future versions "*Equip" might be used to tick the Equip item.
I have reserved those characters for future use in cases such as this.
Hmm... So what if we want to tick the first item and use the index-based return value? That would take up two positions. Maybe it should be something more like this?
"! | *first item"
If the first item starts with !, just enable the flag and drop that item from the list
"! | *first item"
If the first item starts with !, just enable the flag and drop that item from the list
Well, ticking isn't implemented, that was an example.
However to answer your question, if the first character is "!" then it is removed, and then the rest of the list treated in the usual way. However the fact that it was there is remembered for the way the results are returned.
Using the "!" in this way however falls within the scope of "reserved characters".
However the current behaviour is sort-of what you suggest anyway, the "!" is removed, so if you wanted to start a submenu, or use a "!" you could then do so.
It doesn't occupy a list position - I have clarified the documentation to make that clear.
[EDIT]
And if you didn't want numeric results, but wanted to use the "!" then you would use: (space) !
The documentation for WindowMenu says "Leading and trailing spaces are removed from each item." - and thus the extra space would not have any effect (apart from defeating the test of "!" in the first position).
However to answer your question, if the first character is "!" then it is removed, and then the rest of the list treated in the usual way. However the fact that it was there is remembered for the way the results are returned.
Using the "!" in this way however falls within the scope of "reserved characters".
However the current behaviour is sort-of what you suggest anyway, the "!" is removed, so if you wanted to start a submenu, or use a "!" you could then do so.
It doesn't occupy a list position - I have clarified the documentation to make that clear.
[EDIT]
And if you didn't want numeric results, but wanted to use the "!" then you would use: (space) !
The documentation for WindowMenu says "Leading and trailing spaces are removed from each item." - and thus the extra space would not have any effect (apart from defeating the test of "!" in the first position).
Nick Gammon said:
It doesn't occupy a list position - I have clarified the documentation to make that clear.
It doesn't occupy a list position - I have clarified the documentation to make that clear.
Ahh, okay. Got it.