0

I am making a program which finds duplicate files in a directory, but when the directory it is searching has too many of those files it will crash the application. I was wondering if there is a way to buffer the amount of files it grabs. Here is the code that does the thing I am explaining:

string[] filePathsb = Directory.GetFiles(
      @"" + Dirfind, "*" + filetyperest, SearchOption.AllDirectories);

for (int i = 0; i < filePathsb.Length; i++)
   {

     ListBoxItem itm = new ListBoxItem();

     try
     {
        List<TodoItem> items = new List<TodoItem>();

        filelistboxitem.Items.Add(new TodoItem() { Title = "" + filePathsb[i], Deletea = "" + i });
     }
     catch (Exception ex)
     {
        System.Windows.Forms.MessageBox.Show("Error occurance: " + ex);
     }

}

Just a note: this works fine when there are about < 50 files.

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • Define "crash the application". Adding 50 items, or even 200, to a listbox should not cause problems. Adding thousands of items to a listbox can be a problem (in addition to being a poor user experience). Do you get an exception (details?), does the program lock up, or what exactly? – Eric J. Apr 30 '14 at 19:04
  • I do not get any exception from what I think is it happens when i do this: 'string[] filePathsb = Directory.GetFiles(@"" + Dirfind, "*" + filetyperest, SearchOption.AllDirectories);' –  Apr 30 '14 at 19:05
  • so the crash just makes the window freeze when I run the function –  Apr 30 '14 at 19:07
  • Have you considered using a different Thread for the Directory.GetFiles call? –  Apr 30 '14 at 19:07
  • 1
    i agree with Eric... please describe the "crash" as it happens. i built my own FileSync C# app, and i once ran it against a dir that had something like 7000 files in it and it didn't crash anything. Now it did freeze the app until all the files were read, so i switched to threading to keep the UI responsive... – MaxOvrdrv Apr 30 '14 at 19:07
  • the program just literally locks up I will show you a video gif in a sec –  Apr 30 '14 at 19:09
  • @andrew196: Now many files were loaded for the gif you are going to add? – Eric J. Apr 30 '14 at 19:09
  • my computer isnt even slow I have got an i7 processor –  Apr 30 '14 at 19:10
  • Have you tried debugging? This is a really simple for loop, it shouldn't be happening. – cr0ss Apr 30 '14 at 19:14
  • ah my bad I had it open in the background it just took about 1.5 minutes to load all of the files. But I wouldnt have thought it world have taken that long. @EricJ. There were about 1000+ files –  Apr 30 '14 at 19:15
  • 1
    I've updated title of your post based on your comments - please verify if changte is accurate/update. Please *don't* use "crashes" as "does not update UI/freezes" - "crash" for most readers means "throws unhanded exception". – Alexei Levenkov Apr 30 '14 at 19:17
  • @andrew196: Not unexpected. Have a look at my answers for two solutions. – Eric J. Apr 30 '14 at 19:17

3 Answers3

2

Try using the Backgroundworker thread for finding files.your UI will not freeze then and file finding logic will run in 'background'

amolDotnet
  • 139
  • 6
2

WinForms can become quite slow and unresponsive if you add many items to a ListBox. This is particularly true if, as in your example, you do the adding from the UI thread. The UI will freeze up until the last item is added.

What can I do?

A simple improvement is to call

SuspendLayout();

before your loop starts, and

ResumeLayout();

after the loop completes. That will reduce the cost of updating the listbox, so the whole thing completes faster.

How Can I Prevent Locking the UI Entirely?

You can use threading to update the list in the background. For WinForms, BackgroundWorker is commonly used. Note that you cannot directly update the UI from the BackgroundWorker, as they run on different threads. The usual event mechanism ReportProgress does not apply in this situation, since you want to continually update the UI until all files are loaded. Instead, you can use the approach outlined here:

Accessing UI Control from BackgroundWorker Thread

Community
  • 1
  • 1
Eric J.
  • 147,927
  • 63
  • 340
  • 553
0

Just want to share my experience when using multi-thread MFC application. Do not use Wait Functions in the main thread which is handling the message loop. Otherwise it will enter a infinite dead loop.