While the idea of sorting hash tables has been brought up (and dismissed?) many times, I feel mIRC lacks some much needed flexibility in this area.
Hash order would not (necessarily) use the item or data to sort the order in which data is retrieved, instead, an 'index' has to be maintained by the user/script with the /hord command:
/hord <name> <item> [data]
Obviously this looks pretty much like the /hadd command, the user adds an 'order' to an item (or removes it), and the $hfind() identifier is extended to become:
$hfind(name/N, text, N, M, S)
Where S specifies how mIRC will sort the results for the given $hfind:
n: numeric sort
a: alphabetical
c: channel prefix sort
r: reverse order
(the same flags as $sorttok)
Additional 'i' and 'd' flags make mIRC use the tables item and data respectively, instead of using the hord index. All other $hfind() properties are the same, if S is not specified mIRC performs the 'regular' $hfind(). An '.order' property could also be added to the $hget() command.
I'm not sure if this is feasible, however it would be a lot easier and faster then any scripted solution.
Any thoughts?
