Getting the names of files have extension of mp3 from filesystem??

omegazafer

hi, How can I get all names of files which have extension of mp3 from filesystem (c:\ part of computer for example). I can get only the names of files with extension of mp3 in only one folder by using beloved code. By this code,I can't get, if there are mp3 files in subfolders, but I want to get all mp3 files' names under c:\ part of computer. private void button1_Click(object sender, EventArgs e) { System.IO.DirectoryInfo di = new System.IO.DirectoryInfo(@"C:\"); System.IO.FileSystemInfo[] fi = di.GetFileSystemInfos(); foreach (System.IO.FileSystemInfo f in fi) { if (f.Extension==".mp3") { richTextBox1.Text += f.Name; richTextBox1.Text += Environment.NewLine; } } richTextBox1.SaveFile(@"C:\mp3ler.xls",RichTextBoxStreamType.PlainText); }

Anthony Mushrow

Recursion:

void GetMP3(string Path)
{
...

foreach(FileSystemInfo f in fi) {
if(f.Extension == ".mp3") {
richTextBox1.Text += f.Name;
richTextBox1.Text += Environment.NewLine;
}
}

foreach(DirectoryInfo d in di) {
GetMP3(d.FullName);
}
...
}

The function will keep calling itself for all subdirectories within a folder, quite clever when you think about it. That code might not work, but you get the idea. You may also need to call Application.DoEvents() somewhere too, so that your window doesn't lock up while you trawl through the compy looking for mp3's

My current favourite word is: PIE! I have changed my name to my regular internet alias. But don't let the 'Genius' part fool you, you don't know what 'SK' stands for. -The Undefeated

Skippums

Be sure to run the code from the prior post in a separate thread, or Windows will assume your program is "hung" for long directory searches (such as the entire C drive), and when you do a ctl-alt-del your program will appear in the list as not responding (if not in a separate thread). Jeff

Anthony Mushrow

Thats why i added in to use Application.DoEvents(). It gives control to the main window to do what it needs to, process messages, redraw, etc. Though i agree that you should probably put it in a separate thread, although that will make it a little more difficult to update your textbox, though it shouldn't be too much trouble.

My current favourite word is: PIE! I have changed my name to my regular internet alias. But don't let the 'Genius' part fool you, you don't know what 'SK' stands for. -The Undefeated

Luc Pattyn

hi, Directory.GetFiles(string path, string searchPattern, SearchOption searchOption) searches recursively if you ask for it. :)

Luc Pattyn [Forum Guidelines] [My Articles]

this months tips: - before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use PRE tags to preserve formatting when showing multi-line code snippets

Jared Bienz MSFT

Actually, Application.DoEvents isn't really the best way to handle that. You're absolutely right that the application should yield to the UI thread so the application remains responsive, but Application.DoEvents forces the application message pump to run and isn't recommended. Ideally the code above should be performed on a separate thread from the main UI thread. There are many ways to do that including creating a new thread, using the ThreadPool or asynchronous execution of a delegate (delegate.BeginInvoke / EndInvoke). But one of the coolest ways to execute code off the UI thread is the Dispatcher class. You can use the Dispatcher to execute code with various priority levels and even postpone execution until the application is idle. Note that Dispatcher is new to .Net 3.0, so if you're tied to 1.x or 2.0 then you won't be able to use it. You can read about the Dispatcher here[^]. Unfortunately, once this code is running on a separate thread you still have to get back to the UI thread to update controls. If you have a listbox, for example, and you want to add a ListboxItem for each file you find you won't be able to do it from the worker thread. You can get around that using Control.Invoke, but there's an even easier way if you're in .Net 3.0 or later. That's the BackgroundWorker[^] component, which will help you in easily setting up the background thread to execute your code and even gives you a very easy way to communicate back to the UI thread. BackgroundWorker is certainly the easiest, but if it's too restrictive for what you're trying to do make sure you check out some of those other options. Regards, Jared Bienz

My posts may include factual data, educated guesses, personal opinion and dry humor. They should not be treated as an official Microsoft statement.
Sites of Interest: MSDN Events | US ISV Team Blog

Jared Bienz MSFT

The overload of Directory.GetFiles that takes a SearchOption is only available in .Net 3.0 or later, though I agree it's the best option. Note that this can still take a long time and should still potentially be run on a separate thread.

My posts may include factual data, educated guesses, personal opinion and dry humor. They should not be treated as an official Microsoft statement.
Sites of Interest: MSDN Events | US ISV Team Blog

omegazafer

Thanks for your replies, Is there an easier way for this? :)

Luc Pattyn

Jared Bienz [MSFT] wrote:

The overload of Directory.GetFiles that takes a SearchOption is only available in .Net 3.0 or later

I have it running on 2.0, it runs fine except it fails searching at the device level (such as path="C:\") due to an access denied on "C:\System Volume Information\".

Jared Bienz [MSFT] wrote:

should still potentially be run on a separate thread

I fully agree; I would suggest to do allmost all multi-file operations on a separate thread, and in a try-catch construct. :)

Luc Pattyn [Forum Guidelines] [My Articles]

this months tips: - before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use PRE tags to preserve formatting when showing multi-line code snippets