If GetOpenFilename is extremely slow, try renaming your .exe

[CLR]

If GetOpenFilename is extremely slow, try renaming your .exe. It took me hours to find this 'solution'. 

CFileDialog / GetOpenFileName() freeze application. Solution: rename executable!
http://www.itlisting.org/5-windows/98817ccb39756fca.aspx

GetOpenFilename: slow navigation pane initialization
http://social.msdn.microsoft.com/Forums/da-DK/vcgeneral/thread/e898fea1-1924-44c4-b8db-b2d5add05178

[jj2007]

Hilarious! Would be nice to debug it to find out where it hangs...

[CommonTater]

If GetOpenFilename is extremely slow, try renaming your .exe. It took me hours to find this 'solution'. 

CFileDialog / GetOpenFileName() freeze application. Solution: rename executable!
http://www.itlisting.org/5-windows/98817ccb39756fca.aspx

GetOpenFilename: slow navigation pane initialization
http://social.msdn.microsoft.com/Forums/da-DK/vcgeneral/thread/e898fea1-1924-44c4-b8db-b2d5add05178

I doubt it's actually about the name of the executable... more likely it's about junk in the struct and text buffers used to return the selected filename(s), which in some cases might be the name of the executable... 
 
GetOpenFileName() and GetSaveFileName() use the same struct. You should always clear the struct when you create it, and also clear the buffer for the returned name.  Any garbage in either will cause problems similar to those noted.

Code: [Select]


    OPENFILENAME  ofn = {0};                 
    WCHAR         name[MAX_PATH + 1] = {0};   
 
    ofn.lStructSize = sizeof(OPENFILENAME);
    ofn.hInstance   = gInstance;
    ofn.hwndOwner   = gMainWind;
    ofn.lpstrFile   = name;
    ofn.nMaxFile    = MAX_PATH;
    ofn.lpstrTitle  = L"Test Dialog";
    ofn.nFilterIndex= 1;
    ofn.lpstrFilter = L"Text Files\0*.txt\0All Files\0*.*\0\0";
    ofn.Flags       = OFN_NOVALIDATE;
   
    if(!GetSaveFileName(&ofn))
      return 0;


[CLR]

If GetOpenFilename is extremely slow, try renaming your .exe. It took me hours to find this 'solution'. 

CFileDialog / GetOpenFileName() freeze application. Solution: rename executable!
http://www.itlisting.org/5-windows/98817ccb39756fca.aspx

GetOpenFilename: slow navigation pane initialization
http://social.msdn.microsoft.com/Forums/da-DK/vcgeneral/thread/e898fea1-1924-44c4-b8db-b2d5add05178

I doubt it's actually about the name of the executable... more likely it's about junk in the struct and text buffers used to return the selected filename(s), which in some cases might be the name of the executable... 
 
GetOpenFileName() and GetSaveFileName() use the same struct. You should always clear the struct when you create it, and also clear the buffer for the returned name.  Any garbage in either will cause problems similar to those noted.

Code: [Select]


    OPENFILENAME  ofn = {0};                 
    WCHAR         name[MAX_PATH + 1] = {0};   
 
    ofn.lStructSize = sizeof(OPENFILENAME);
    ofn.hInstance   = gInstance;
    ofn.hwndOwner   = gMainWind;
    ofn.lpstrFile   = name;
    ofn.nMaxFile    = MAX_PATH;
    ofn.lpstrTitle  = L"Test Dialog";
    ofn.nFilterIndex= 1;
    ofn.lpstrFilter = L"Text Files\0*.txt\0All Files\0*.*\0\0";
    ofn.Flags       = OFN_NOVALIDATE;
   
    if(!GetSaveFileName(&ofn))
      return 0;


Thanks for the tip. However, if I copy and rename notepad.exe to 'plutao.exe' I can see the same problem in the file dialog.

[CommonTater]

Thanks for the tip. However, if I copy and rename notepad.exe to 'plutao.exe' I can see the same problem in the file dialog.

And what guarantee do you have that notepad is correctly clearing those memory regions before using them?
 
I'm not saying this is the problem... but it's a far more likely answer than the filename.
 

[Stefan Pendl]

May be you have just found a problem with your AV software.

You must think about what software does monitor folder and file access, so you can work out the correct solution.

You may even have Tortoise SVN installed and the overlay icons slow down the system.

Many things can have an impact on the performance of the file system.

[CLR]

Thanks for the tips.

[Stefan Pendl]

Which Windows release(s) do you experience the problem?

[CLR]

Which Windows release(s) do you experience the problem?

Hi Stefan. It's Windows 7 Home Premium - x64.

[Stefan Pendl]

It's Windows 7 Home Premium - x64.

Running that since Win7 was released, but never encountered the issue described here.

I really think this problem is a result of multiple influencing factors, else it would have been taken care of already with a Windows update.

In the file open dialog is there the new side panel displayed (Favorites, Libraries, Computer and Network) or the old one?

[CLR]

It's Windows 7 Home Premium - x64.

Running that since Win7 was released, but never encountered the issue described here.

I really think this problem is a result of multiple influencing factors, else it would have been taken care of already with a Windows update.

In the file open dialog is there the new side panel displayed (Favorites, Libraries, Computer and Network) or the old one?

I see the new side panel.
Unfortunately everything is fast again and I haven't found the problem root cause.

[Stefan Pendl]

Unfortunately everything is fast again and I haven't found the problem root cause.

So what changed yesterday?

AV update, favorites and/or libraries cleaned up, etc.?

[CLR]

So what changed yesterday?

AV update, favorites and/or libraries cleaned up, etc.?

Yesterday, nothing.

A few days ago
- Avast anti-virus disabled. No effect.
- deleted program entry from HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\Shell\MuiCache. No effect.
- deleted program entry from C:\Windows\Prefetch\. No effect.