menu oddities

Hi, i have a menu
list menu =["1","2","3","4"];

in the listen i say
integer ch = llListFindList(menu,[message]);

cute..
but
the buttons are -presented- as

4
1 2 3

whut?!

the button with '4' i on top on a row of its own
then 3 button follows in the order 1 2 3

I would prefere
1 2
3 4

questions:
1) why (oe..) is the buttons presented
4
1 2 3
?!

2) what should i do to get the prefered presentation
eg
1 2
3 4

i'm so puzzled of this :/

BR
ab

I think the buttons are presented as 1-2-3, then, then next row appears above the first row. Kinda goofy how it comes out sometimes, you just have to play with the list order to get something that makes sense.

You can prefer whatever you want, but the world will not change for that
Buttons are placed left to right, down to up and will fill max 3 columns by 4 rows

It's possible to arrange the buttons the way you want... if you always have rows of 3 buttons. Add a blank space for the unused buttons.

list menu = ["3", "4", " ", "1", "2", " "];

BUT don't forget to filter. When you receive " ", you must re-display the dialog.

A blank space or anything like "-/-", "-" or whatever. You just have to ignore it in the listen() event.

See the order_buttons() function under the Useful Snippets section on this page in the SL Wiki: http://wiki.secondlife.com/wiki/LlDialog

or just remember that they are displayed left to right then bottom to top....

yes LL is stupid that way, and now that it's been ingrained so long, changing it would break most menuing systems.

somewhere on this forum is an automatic list paging system I wrote for buttons, which incidental corrects their order to be left to right, top to bottom.

The order is following the directions in a conventional XY coordinate system. What is stupid about that?

*sigh* oh well .. as stated changes to this is not likely - i dont like the way though, then again i dont like fried liver either and thats properly not disapearing ..
Thanks for explaining :)
BR
ab

not quite, more like an inverse LineFeed, a forced break chat scroll, or a tetris drop. which is how I expect the dialog image is built. the space is extended dynamically in height, but width remains fixed, ie, not following an X/Y expansion. additionally the placement expansion occurs interior to the dialog, rather at the edge. generally, an y/x expansion would have either both fixed, or both dynamic, and a flow leading from a fixed position, even an aligned to centered position wouldn't be unheard of.

as it is, it breaks those conventions, not to mention the visual structure convention, and the default (for the client language) text conventions.... hence, stupid =) (IMHO)

It doesn't follow the logic of reading from left to right and from the top to the bottom of a page, which is stupid because most people, including a good many content creators, expect to read a menu like a page of text as opposed to a graph.

I fail to see the problem.
What is stupid is to use numbered keys since LL offers the possibility to write text on the buttons.
When you have text on the buttons you never need to give it one single thought what number the key has.
Your script will not reference a key index anywhere, only the text on the button is important

except that not all button lists are collections, some are sequential, and some you would want to order and group in a particular way (for instance directional positioning controls, previous and next buttons in paged dialogs, and a million other option that are best expressed in standard text scroll order.)

You're absolutely right that a collection of color choices, song titles, or dance animations isn't likely to be seriously impacted, either way. however, sequential options, visual order, and progressive groupings are all highly impacted by the unconventional and non-intuitive method LL chose for displaying dialog buttons.

to OP:

Ordering Buttons Function that I use which works just fine and keeps everything in the correct sequence.

//===== Order the Buttons into right sequence for DIALOG MENUS
list btn_order(list btns)
{
return llList2List(btns, -3, -1) + llList2List(btns, -6, -4)
+ llList2List(btns, -9, -7) + llList2List(btns, -12, -10);
}


To use with llDialog Here is another snippet

llDialog( llGetOwner(), "Make your Selection:",
btn_order(["One","Two","Three","Four","OPTIONS"]), CHANNEL);

IF you have a list that you want to sort into a specific order for the buttons, you can either:
A) Order the list as you wish to present it manually above
B) Sort the list Alphabetically in Ascending or Descending order.

Hope this answers the original question.

WhiteStar

Actually it is not totally illogical. If you do use numbered keys, rather than text, then the list [1,2,3,4,5,6,7,8,9] correctly appears as a numeric keypad, with 123 at the bottom and 789 at the top. I wonder if the original intent was not to use it as a keypad and then the text was added as an afterthought.

that wouldn't surprise me in the least, although the logic I've heard for numeric keypad ordering (placing the first keys nearest the fingers, or mounting lower numbers lower on the keypad) always seemed a bit iffy... visually it's highly distracting for english speakers, and really I don't know any language that uses that particular order. thankfully the solution isn't too complex (well at least not until you add pagination) FIFO rebuild in 3 element strides.