GetOpenFileName problem with double click

[jboyes]

My new program selects files using a GetOpenFileName dialogue. The files are .PDFs and, if I double click to select one, the program crashes.

I turned to one of my previous programs that selected .DMX files and this one never crashed. I spent nearly a whole day comparing the two dalogue segments but could find no differences.

I went back to my new program and found that using any filetype other than .PDF it worked flawlessly. I tried defaulting .PDF files to be opened with other applications including Notepad but that didn't fix things either.

I have now run out of ideas and would appreciate any help from the experts.

Thank you,

John.

[jj2007]

John,

Adobe is a recipe for crashes, but it could well be something else. Do the files open with a double click from Windows Explorer?

Try showing a messagebox with the filename before the ShellExecute (or whatever you use to open the file). Put brackets before and after: [MyFile.pdf]

There is another issue: the dialog has an internal exception, which shows up when you debug it e.g. with OllyDbg. Normally that's not a problem, though.

[TimoVJL]

Is OPENFILENAME structure initialized properly ? Zeroed first or static variable ?

[jboyes]

Many thanks for your suggestions gentlemen. I did initialise the OPENFILENAME structure but, as an experiment, I temporarily removed that code and it made no difference.

Like TimoVJL, my guess is that Adobe is to blame but I have also loaded Foxit with a view to getting rid of Adobe Reader some day. That might be significant.

I now have the program fully working. I have to keep the mouse away from filenames as much as possible to avoid tooltips. I also have to single click to select the multiple files and, if I can get back to the 'Open' button smartly, everything works fine.

I shall keep looking at the problem now and again but the panic is over.

Thank you for your help.

John.
 

[frankie]

Check what flags you set.
Try this code:

Code: [Select]

BOOL GetFileName(HWND hWnd, LPTSTR lpstrFile)
{
*lpstrFile = '\0';

OPENFILENAME ofn = {0};
ofn.hwndOwner   = hWnd;
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.lpstrFile   = lpstrFile;
ofn.nMaxFile    = MAX_PATH -1;
ofn.lpstrFilter = "TXT\0*.txt\0All Files\0*.*\0\0";
ofn.lpstrTitle  = "TXT Files";
ofn.Flags       = OFN_OVERWRITEPROMPT;
ofn.lpstrDefExt = ".txt";

return GetOpenFileName(&ofn);
}
This works for me.

[jboyes]

Now here's an interesting thing:

I just tried my program again but chose 'All files' instead of 'PDF files' before selecting the file to open. It worked perfectly every time; no crashes at all.  So it must be something to do with the 'Files of type' being .PDF

This is obviously a problem due to my computer which has had every version of Acrobat Reader loaded in its time. And now I have added Foxit, the poor thing is probably getting very confused.

Its not a windows problem that I can expect to get help from in this forum so I think we shold drop the subject.

Just for completeness frankie, here is the code I use to initialise the OPENFILENAME structure:

Code: [Select]

ZeroMemory(&ofn , sizeof(ofn)); // Initialise structure to zero
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = hDlg;
ofn.lpstrFile = FileName;
ofn.lpstrFile[0] = '\0';
ofn.nMaxFile = sizeof(FileName);
ofn.lpstrFilter = "All files\0*.*\0PDF files\0*.pdf\0\0";
ofn.nFilterIndex =2;
ofn.lpstrFileTitle = NULL;
ofn.lpstrDefExt = ".pdf";
ofn.nMaxFileTitle = 0;
ofn.lpstrInitialDir=NULL;
ofn.Flags = OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST|OFN_EXPLORER|OFN_ALLOWMULTISELECT;

The OPENFILENAME structure itself is declared with my globals because I use it in more than one function.

Thanks again for all the help.

John.

[PhilG57]

Hi.  I'm now seeing the same problem where during file selection, if I hover the cursor over a file selection, my program crashes at location 401280.  I continue to experiment with the initialization of OPENFILENAME, and the actual parameters to GetOpenFileName but to no avail.  I my case, the file I am trying to select is a user file type of "vcp".  More details hopefully later.

[PhilG57]

After playing with my code and searching the web, I've concluded this is a Windows problem, and since I'm running Pelles v7 on Windows XP, I'm not looking for a fix real soon...

The best explanation I can find is that Windows is failing in the GetOpenFileName code.  Specifically, while you're thinking about a file to select to satisfy the GetOpenFileName request, when you hover your mouse over a potential file name, Windows wants to display those file properties (type, date, size, etc.) in a little yellow box near the file name.  Somehow that causes GOFN and your program to crash.  From what I can find there is no known solution....

I have noticed that if you quickly select a file (before Windows thinks it has to display the file properties in a little yellow box), the GetOpenFileName completes normally,  Also, for me, the GOFN does not crash if I run my program in "execute" mode rather than "debug".  Hope this helps.

   

[jj2007]

After playing with my code and searching the web, I've concluded this is a Windows problem, and since I'm running Pelles v7 on Windows XP, I'm not looking for a fix real soon...

After playing extremely often with my own GetOpenFileName code and searching the web intensely, I've concluded that problems are related to sloppy coding. Attached an executable with its source (in RTF format, assembly, sorry...). Even after intense hovering over files with Chinese names etc, I could not crash it on XP and 7-64. Attached is the Unicode version, but the ANSI version behaves exactly the same. The proggie is built in debug mode, so OllyDbg could show you how it is built.

If you are able to code a reproducible example in 32-bit code, and you can insert an _asm int 3;  right before the call to GetOpenFileName, post the example here, along with a description how to crash it, and I will be happy to find the bug.

[Vortex]

Hi PhilG57,

Checking your code :

Code: [Select]

ZeroMemory(&ofn , sizeof(ofn));
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = hDlg;
ofn.lpstrFile = FileName;
ofn.lpstrFile[0] = '\0';   <--- Should be : FileName[0]=0; The current code changes the pointer,not the filename
ofn.nMaxFile = sizeof(FileName);
ofn.lpstrFilter = "All files\0*.*\0PDF files\0*.pdf\0\0";
ofn.nFilterIndex =2;
ofn.lpstrFileTitle = NULL;
ofn.lpstrDefExt = ".pdf"; <--- Do not put a dot in the default extension name.
ofn.nMaxFileTitle = 0;
ofn.lpstrInitialDir=NULL;
ofn.Flags = OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST|OFN_EXPLORER|OFN_ALLOWMULTISELECT;
About the first modification indicated above, the dialog will crash when it can't access the buffer.

Second, the ofn.lpstrDefExt should not have a dot in it. This will prevent the dialog from opening reliably. Also when opening files, it is best to leave that line blank. It is meaningful only when assigning a default extension to new
filenames with no extension.

[aardvajk]

ofn.lpstrFile = FileName;
ofn.lpstrFile[0] = '\0';   <--- Should be : FileName[0]=0; The current code changes the pointer,not the filename

What he has, and what you propose are equivalent.

The main problems in GetOpenFileName and friends come from having dodgy shell extensions on your computer rather than failing to init the simple structure. GetOpenFileName is pretty much like having a mini-explorer in your app, except without the protection that Explorer has built in to stop it crashing.

[PhilG57]

Hi and Happy New Year,
   I appreciate the suggestions and offers for help.  The code referenced just above by Vortex is not mine but that posted earlier by jboyes.  However my code is basically identical and changing the '\0' for 0 in the OFN fields has no effect.

   My code is attached and I will gratefully accept any offers to correct the OFN calls.  In reply to aardvajk, I do have a bunch of shell extensions like Git, Tortoise, and Change Attributes.  They have been there quite awhile so I really can't point the blame at them...

   To test: compile and run under debug; select CheckIn from the main menu, and CheckIn again from that sub-menu.  Hover over any displayed filename or directory for a second or two and the program should blow up.   

   Thanks again. 

[TimoVJL]

No crashing so far.

[czerny]

To test: compile and run under debug; select CheckIn from the main menu, and CheckIn again from that sub-menu.  Hover over any displayed filename or directory for a second or two and the program should blow up.   

You should downgrade to a proper OS like win2k!
Here is all ok!

[jj2007]

Happy New Year & no crash on Win7-64