I created a bunch of array snippets that used hash tables to store sorted information.
Whilst they are unsorted by nature, if you just use numbers as key names then you can manage the sort yourself.
For example, if you were to sort this data alphabetically: z b d h j e, it would become: b d e h j z, you could then add each letter to the hash table with a number as key:
hadd -m table 1 b
hadd -m table 2 d
hadd -m table 3 e
hadd -m table 4 h
hadd -m table 5 j
hadd -m table 6 z
echo -a $hget(table,1) = b
echo -a $hget(table,2) = d
echo -a $hget(table,3) = e
echo -a $hget(table,4) = h
echo -a $hget(table,5) = j
echo -a $hget(table,6) = z
And there you have it, sorted hash tables
The only thing you need to keep in mind when using this method is that if you were to delete an item you'd have to reshuffle every item after that position so there are no gaps, unless you come up with a decent method to iterate through the table until all items have been found even if there are gaps. This is where the main overhead comes in, it's quite slow to reshuffle 1,000+ items.
In the past I've seen similar ideas.
I know most problems have a solution.
But I'll recap what I said:
My interest in this * Error creating window (and * Error creating dialog) is because in ran in both, the first when having alot connections/channels and the latter when I try to test my script between two mIRC instances (it has a kind of remote control through sockets, where remote configuration files are sent and loaded in quite big dialogs).
Beside this, my script uses an amount custom windows for script configuration data, but that amount doesn't increase with the amount irc connections so it's not a problem as worse as the irc windows.
I found the way custom windows can be used very handy.
They keep their order by themselve, they are fast and various powerful commands work on them, /filter can be used to sort on token position, $fline() is handy to find a line with a certain token on a certain position, and several other commands provide in add/delete/insert/etc of one single line.
So, for every sort of task, there's a choice.
The big 'but' of this is that the window-being of this storage solution is actually an unwanted side-effect.
mIRC should have a similar memory structure, maybe in the form of an array where the 'slot'-names are 'behind the scenes', leaving only the value part. I don't know if such structure already exists under some other name.
And of course, also commands similar to what now is available for custom windows.
Clickhere once said that a dll could mimic this easily and wouldn't be hard to write, but I'm not a big fan of using dll's for such script core functionality, they create a heavy dependency on a completely third party-'plugin' to a main commercial application. If for any reason the dll becomes unusable then the mIRC script completely relying on it follows it into the grave.
Back to the question I had, suppose this * Error creating window stops a channel window from being created, could it be so programmed that mIRC can be told to not create a window (thus on purpose)?
Because that would allow scripts to be on alot networks/channels, unlimited by this resource problem, while still be able to use all what mIRC has available as functions, because the only alternative is to use socket connections to the irc servers, inflicting the need to do -everything- in script, from protocol parsing till IAL, notify, etc.
The question is if this is realistic, as is, how much are mIRC's functions dependent on the existence of the window.