Select (drop-down) lists in Thingy appear to have their items randomized. When select lists are long, as is the case when linking between two Things with more than a handful of records, this makes Thingy effectively unusable because it is too difficult to scan long, un-sorted lists for the desired.

(This is why I have labeled this as Critical as opposed to Minor -- it prevents users from doing anything but the most rudimentary linking between Things.)

I have found the problem to exist in at least two different situations. One is the above-mentioned select lists used to link records to other Things. The second is when defining a fixed list of options for a field in a Thing. As the result of another bug (http://www.webgui.org/use/bugs/tracker/12340) I began switching from the "piped" version of defining key/value pairs to the hash ref alternate format. (As noted in the previous bug,  http://www.webgui.org/content-managers-guide-wiki/thingy mentions two ways to define key/value pairs for Thingy, though the Thingy edit hoverhelp only mentions the pipe method.) Using the hash ref syntax in these cases causes the parsing errors mentioned in the bug report to stop appearing in my logfiles, but it had the downside of the select lists (and other list-type inputs) now becoming randomized.

The problem appears to be that hash refs being passed to WebGUI::Form::List are not being tied to maintain order by WebGUI::Thingy.

Additionally, the list of options queried in links-to-other-Things appear to not have any sorting when queried from the database. The order appears to be that in which the data were entered. One solution might be to sort based on the search sort setting for that Thing, but really, if you are setting up a select list, alphabetizing the list (option text, rather than values) makes the most sense.

For the other case of select lists with defined values, it's probably best to retain the original value in which the Thingy editor defined them.