NO

Author Topic: If GetOpenFilename is extremely slow, try renaming your .exe  (Read 12546 times)

CLR

  • Guest
If GetOpenFilename is extremely slow, try renaming your .exe
« 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

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

Offline jj2007

  • Member
  • *
  • Posts: 536
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #1 on: March 08, 2013, 07:19:40 AM »
Hilarious! Would be nice to debug it to find out where it hangs...

CommonTater

  • Guest
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #2 on: March 08, 2013, 03:17:59 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

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

  • Guest
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #3 on: March 08, 2013, 07:43:32 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

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

  • Guest
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #4 on: March 09, 2013, 02:14:57 AM »
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.
 

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #5 on: March 09, 2013, 09:45:55 AM »
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.
---
Stefan

Proud member of the UltraDefrag Development Team

CLR

  • Guest
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #6 on: March 09, 2013, 10:28:15 PM »
Thanks for the tips.

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #7 on: March 10, 2013, 09:35:57 AM »
Which Windows release(s) do you experience the problem?
---
Stefan

Proud member of the UltraDefrag Development Team

CLR

  • Guest
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #8 on: March 10, 2013, 10:09:04 AM »
Which Windows release(s) do you experience the problem?
Hi Stefan. It's Windows 7 Home Premium - x64.

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #9 on: March 10, 2013, 02:13:33 PM »
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?
---
Stefan

Proud member of the UltraDefrag Development Team

CLR

  • Guest
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #10 on: March 10, 2013, 09:07:43 PM »
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.

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #11 on: March 11, 2013, 08:49:10 AM »
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.?
---
Stefan

Proud member of the UltraDefrag Development Team

CLR

  • Guest
Re: If GetOpenFilename is extremely slow, try renaming your .exe
« Reply #12 on: March 11, 2013, 11:11:41 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.