You don't have to "dump" it to anywhere. Just /hsave it. Unless /hsave is taking a long time, it should be fast.
Thats what I meant by "dumping", it takes too long.
So I'd like to see having hfind doing that stuff for me;)
Ok, just checking. Often when people talk about dumping data, they are talking about writing the data individually (as you'd have to do to go directly from a hash table to a window).
qwerty brings up a good point about putting data into a new hash table if the number of matched results is going to be very high. 50 results probably wouldn't be bad, but thousands would be. For the larger numbers, a window might actually work better. I just don't really like being forced into that method. If you know your results will be small, it's a lot nicer not to have a window created whenever you search. At least I think so. Also, windows become a problem if you are already in a lot of channels or have a lot of query windows open and then have a script or multiple scripts automatically doing searches of a variety of tables. There's a limit to the number of windows you can open at one time and you could end up hitting the limit and then your search stops working until the number of windows is reduced. Whereas another hash table or even a file output would always work as long as you have memory/drive space. That's a rare situation, of course. Just something to consider for the rare few who actually do keep that many windows open on a regular basis. It might be that so few fit that description that it's not worth worrying about. I just wanted to bring it up for consideration. Also, if you have a lot of tables and a script that can automatically search them, you could easily end up with 10, or 20, or more search windows. Not necessarily what I'd like to see. Even if the windows are hidden, you're still potentially creating a lot of windows just to search.
And pball also has a good option. Really large hash tables become cumbersome. Once you start working with significant amounts of data, a true database structure, like SQL, is often more useful and efficient. That being said, I've never used SQL with mIRC, so I can't personally say how easy or fast it is from mIRC.
