I think it would be great if mIRC had a tag for $fiindfile that would sort the files be filename, type, size.

It's not mIRC's responsibility to get the files. mIRC uses a libary by windows. Whatever order windows gives them, mIRC recieves them in that same order.

*psst* thats why this was posted as a Feature Suggestion

Even so, mirc can't filter it. The class used gets the filenames from windows, which selects the order they come in. I suppose mirc could use some memory and accept all the possibles, save it into a buffer, filter it, then pass it onto the user. But even in these cases, if a user tried to sort the directory (and all subsections here of) C:\, it would get very memory intensive.

I'm not dismissing the technical issues, I'm only reminding you that its just a suggestion, and as valuable as any of the other suggestions here.

This is directed at no one in particular, but it seems that it is becoming more popular to find reasons why things *can't* work instead of how things can. I guess this is just my own little hope of seeing more constructive criticism here instead of all the negative

-chris

I wasn't dismissing the suggestion. I was merely pointing out that its not mIRC's responsibility of getting the files in a perticular order. My point was simply that sorting files isn't possible without some form of additional overhead on mIRC's part. Additionally, though it may sound like a possible addition, just reminding that if mIRC did take on the responsibility of file sorting, that large searches could become very memory intensive and slow.

mIRC should be able to sort the files how the user wants. It has been said that it sorts them however Windows sort them, however, this is untrue. I have files sorted by filename, and $findfile returns them in a very odd order, such as

05.ex
01.ex
02.ex
12.ex
04.ex

This is not being sorted by filenames. Plus, the default would obviously be the same as it is right now, with no extra sorting. If you are dumb enough to try and use it to sort all of C:\, its your own damn problem.

Anyway, as of right now, I have only found one solution to this, or, the easiest way. (If mIRC did sorted them, it would be not only faster, but easier yet). The way I've found to sort $findfile results requires going through two while loops. The first one loads all of the results into a sorted @window (which could be hidden if you like), and the second one goes though the lines in the @window and returns them. Then the window is close. This, however, takes up much more processor time than having one single while loop (twice as much, to be exact :P).

If this feature would be added, it would be a great help.

And remember, don't be so negative. It can be annoying when you say "NO! YOU CANT DO THAT BECAUSE...." over and over, while repeating the same reasons.

There is one. I have done this with a mp3 player script.

-------------------------------------------------
xmp3.dir {
window -elhns @plist
aline @plist $findfile(%mp3.dir,*.mp?,0,aline @plist $1-)
filter -wfe @plist $data $+ mp3.txt *.mp?
}
-------------------------------------------------

work wonders too is much faster and auto sorts by file name. I not sure it would work for types though. i do not see why not though. Anyway just posting this here incase someone does need a sort script now

I think what KT is reffering to is the order recieved in the FindFirtsFile and FindNext functions. These are completly independant of the way you sort them in explorer. KT's idea would of course work but it would be completly unuseable. despite the obvious large amounts of memry required the time to completion would be astronomical.

first your listing all the files in memory this is the same time you normally have. then you sort that internal list wich could take a large amount of time. then give the list (one item at a time) back to the script.

If im not mistaken there are methods of refining the FindNext etc.. functions (they use a struct as an arg). Perhaps that way you can get a more refined search

Where exactly are these FindFirstFile and FindNext functions? I'm not seeing those anywhere.

they are Win32 API functions. $findfile is an mIRC script wrapper for those functions (mIRC just calls them for you). aside from a dll you cant access them from a script (perhaps using a com object however).

If you plan on making a dll (think there is one already on www.mircscripts.org) look into FindFirstFile,FindNextFile and FindClose functions in the MSDN

I dont see a method for searching based on filesize but i think ext based searches are possible.

Perhaps this will make more sense to you.

The order that $findfile matches is based on your system's FAT table. The order is typically by creation or modification of the file (often depends on how a program overwrites the file), so you'll get older files first and newer files last.

When you defragment your harddrive however, many defrag programs will sort your FAT table by file name. This would cause $findfile to give mostly alphabetical listings, and then newer files mixed up at the end.

FindFirstFile/FindNext functions are part of Windows API, and are accessable in C++, Visual Basic and other actual programming languages. As said earlier, $findfile simply calls these functions for you. (Just reiterating this to avoid any confusion)

- Raccoon

Depends on the filesystem in use. NTFS returns the files in alphabetical order, while with FAT the files are returned in the order they were were written/created.

Ah yes, that evil evil NTFS.

* Raccoon is also afraid of this new Longhorn (Win2005) filesystem.

Why is NTFS evil?

I think WinFS will be a great feature.
It isn't a filesystem though. More like a file cataloging system, whichl runs on an NTFS filesystem.

[[Sorry, I meant to add a winky-face to that first line.

I have nothing against it personally, except that Win98 doesn't recognize NTFS which has made life difficult at times. And I only know the little I've read about Longhorn, which aren't the greatest of reviews. Guess I flinch easily when it comes to new microsoft "innovations".]]

Ahh...

While (*good suggestion* iswm $1-) { echo NO NO NO! IT'S BAD AND NOT POSSIBLE! }