Something changed in ace a while ago (sometime during BFA I think) that has caused the entries in my dropdowns to no longer be sorted correctly.
The table I give to the select control has key-value pairs that are table-string. The key objects all share the same metatable where I define an __lt function for the class. This allows native lua operators like < and > to work which means table.sort works when those objects are the values of the table.
In the past this meant that the table I gave to the select control displayed the values (strings formatted for display) in the same order you would get running sort on a table of the keys. Users could select a different sort type and under the covers the __lt metamethod would just return a different sort function. It all worked nicely.
Now, the display order matches that of a sort run on the keys after tostring() operation. That is to say, the value keyed by "table: 000001D66FB2EE30" appears above the one keyed by "table: 000001D67106CF50".
So, is this a bug that crept in and might be fixed or was this a deliberate change I'll have to work around or redesign for?
I quite liked that the items in the drop down list were the things themselves, my actual objects. A situation where it was an ordered table with the objects as values and we provide you the function to call on those values to generate the display name would have been good too. I'd like to avoid the situation where I have to keep two tables in sync with another.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSomething changed in ace a while ago (sometime during BFA I think) that has caused the entries in my dropdowns to no longer be sorted correctly.
The table I give to the select control has key-value pairs that are table-string. The key objects all share the same metatable where I define an __lt function for the class. This allows native lua operators like < and > to work which means table.sort works when those objects are the values of the table.
In the past this meant that the table I gave to the select control displayed the values (strings formatted for display) in the same order you would get running sort on a table of the keys. Users could select a different sort type and under the covers the __lt metamethod would just return a different sort function. It all worked nicely.
Now, the display order matches that of a sort run on the keys after tostring() operation. That is to say, the value keyed by "table: 000001D66FB2EE30" appears above the one keyed by "table: 000001D67106CF50".
So, is this a bug that crept in and might be fixed or was this a deliberate change I'll have to work around or redesign for?
I quite liked that the items in the drop down list were the things themselves, my actual objects. A situation where it was an ordered table with the objects as values and we provide you the function to call on those values to generate the display name would have been good too. I'd like to avoid the situation where I have to keep two tables in sync with another.
I'm not sure the Ace3 authors read this forum, otherwise you can post your issue or bug report here https://discord.gg/sVQCHr5