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
Hilarious! Would be nice to debug it to find out where it hangs...
Quote from: CLR on March 07, 2013, 09:15:06 PM
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 (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 (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.
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;
Quote from: CommonTater on March 08, 2013, 03:17:59 PM
Quote from: CLR on March 07, 2013, 09:15:06 PM
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 (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 (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.
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.
Quote from: CLR on March 08, 2013, 07:43:32 PM
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.
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.
Thanks for the tips.
Which Windows release(s) do you experience the problem?
Quote from: Stefan Pendl on March 10, 2013, 09:35:57 AM
Which Windows release(s) do you experience the problem?
Hi Stefan. It's Windows 7 Home Premium - x64.
Quote from: CLR on March 10, 2013, 10:09:04 AMIt'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?
Quote from: Stefan Pendl on March 10, 2013, 02:13:33 PM
Quote from: CLR on March 10, 2013, 10:09:04 AMIt'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.
Quote from: CLR on March 10, 2013, 09:07:43 PM
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.?
Quote from: Stefan Pendl on March 11, 2013, 08:49:10 AM
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.