none
Open dialog box crashes

    Question

  • I can use the Open File dialog generated by the GetOpenFileName() function once or twice, but after that, it crashes when i mouse over a file. It is just the mousing over that crashes it: i can open files as much as i like if i type the name in the edit control.
    Friday, March 16, 2007 11:29 PM

Answers

  • yxrk,

    Maybe try putting OPENFILENAME, both its structure and functions in the CALLBACK where I think it belongs in the first place. However, if you really need to open up a file in the WinMain() then it would seem to me that it might be a good idea to know the file's name and where it is in the first place. Otherwise, you may be fishing in a lake before it got filled up with water, not to mention fish. And it would be safer to do this before you got into the WinMain()'s while GetMessage(&msg,,,) loop.

    On the other hand, re-doing the WinMain()'s while (GetMessage(&msg,,,,)) loop with PeekMessage(&msg,,,) and such stuff may not be such a hot idea with OPENFILENAME's structure. It’s probably getting hit in the face every other fraction of a second with something from somewhere. If so, then your program's stack might have simply overflowed, which would explain why it has a tendency to crash.

    JamesSexton


     

    Tuesday, March 20, 2007 2:01 PM

All replies

  • //============================================================================
    // Initializes the OPENFILENAME structre when the class instance is constructed.
    //============================================================================
    void mWindows::InitOFN()
    {
      ZeroMemory(&ofn, sizeof(OPENFILENAME));
      ofn.lStructSize = sizeof(OPENFILENAME);
      ofn.hwndOwner = hwndMain;
      ofn.lpstrFilter = "Game Level File (*.glf)\0 *.glf\0\0";
      ofn.nFilterIndex = 1;
      ofn.lpstrDefExt = "glf";
      ofn.nMaxFile = MAX_PATH;
      ofn.nMaxFileTitle = MAX_PATH;
    }
    //============================================================================
    // This is called before GetOpenFileName()/GetSaveFileName() is called.
    //============================================================================
    void mWindows::SetOFN(mWindows::OFN_MODE mode)
    {
      static char path_buf[MAX_PATH];
      static char name_buf[MAX_PATH];
      memset(path_buf, '\0', sizeof(path_buf));
      memset(name_buf, '\0', sizeof(name_buf));
      ofn.lpstrFile = path_buf;
      ofn.lpstrFileTitle = name_buf;
      if (mode == OPEN)
        ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;
      else
        ofn.Flags = OFN_OVERWRITEPROMPT;
    }
    Saturday, March 17, 2007 8:08 AM
  • Just to clarify, that was not a solution, just the code i'm using.
    Saturday, March 17, 2007 8:52 AM
  • That problem is a type that is difficult to diagnose. One likely possibility is that somewhere in your code something is writing to memory where it is not supposed to.
    Saturday, March 17, 2007 11:29 PM
  • Thanks very much for the reply.

    It doesn't seem to be my code though: It seems like a bug in the GetOpenFileName() function. What's happening is the mouse-over tooltip will load once, but then next time the dialog launches, it will crash instead of display the tooltip (for files only, not folders). As far as i know, the OPENFILENAME struct has nothing to do with the tooltips displayed in the Open / Save dialog boxes.

    Saturday, March 17, 2007 11:46 PM
  • IMPORTANT NOTE: I just found out that it only crashes when the files are on the desktop. Hmmm...
    Sunday, March 18, 2007 12:01 AM
  • When something does not work the way it is supposed to, don't expect it to work the way it is supposed to.
    Monday, March 19, 2007 5:26 AM
  • ie, wait for microsoft to fix it?
    Monday, March 19, 2007 6:34 AM
  • Why did u call ZeroMemory(&ofn, sizeof(OPENFILENAME)) ?
    you reset the ofn pointer whitout deleting them.
    is it the first and the only initialisation ?

    After the call of ZeroMemory I think that ofn.lpstrDefExt = "glf"; and ofn.lpstrFilter = "Game Level File (*.glf)\0 *.glf\0\0"; are not correctly initialised.

    for me ofn.lpstrDefExt and ofn.lpstrFilter are not allocated but you set it to a temporary variables.

    Did you try this :

    ofn.lpstrDefExt = nex char[MAX_PATH];
    strcpy(ofn.lpstrDefExt, "glf");

    ofn.lpstrFilter = nex char[MAX_PATH];
    strcpy(ofn.lpstrFilter , "Game Level File (*.glf)\0 *.glf\0\0);

    dont forget to call delete [] on destruction.

    Monday, March 19, 2007 1:01 PM
  • Hi ,

    It seems there is no problem in filling the OPENFILENAME structure or calling the GetOpenFileName() function(even the files are on desktop).I tested ur code in my sample.It's working fine.

    What i did is , i made OPENFILENAME ofn as private member of dialog class aswell as InitOFN (modified for .txt files)and SetOFN too.And a button_click handler is defined as following .I could n't produce the crashing error u r reporting.Can u simulate the same bug with a sample and post it?

    ============================================

    void CMFCDlgDlg::InitOFN()

    {

    ZeroMemory(&ofn, sizeof(OPENFILENAME));

    ofn.lStructSize = sizeof(OPENFILENAME);

    ofn.hwndOwner = this->m_hWnd;;

    ofn.lpstrFilter = _T("Text Files(*.txt)\0 *.txt\0\0");

    ofn.nFilterIndex = 1;

    ofn.lpstrDefExt = _T("glf");

    ofn.nMaxFile = MAX_PATH;

    ofn.nMaxFileTitle = MAX_PATH;

    }

    //============================================================================

    // This is called before GetOpenFileName()/GetSaveFileName() is called.

    //============================================================================

    void CMFCDlgDlg::SetOFN(int mode)

    {

    static WCHAR path_buf[MAX_PATH];

    static WCHAR name_buf[MAX_PATH];

    memset(path_buf, '\0', sizeof(path_buf));

    memset(name_buf, '\0', sizeof(name_buf));

    ofn.lpstrFile = path_buf;

    ofn.lpstrFileTitle = name_buf;

    if (mode == OPEN)  //here OPEN is enum define dlg.h file

    ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;

    else

    ofn.Flags = OFN_OVERWRITEPROMPT;

    }

    void CMFCDlgDlg::OnBnClickedButton1()

    {

    InitOFN();

    SetOFN(OPEN);

    GetOpenFileName(&ofn);

    MessageBox(ofn.lpstrFile);

    }

    =================================

    Thanx,

    Ch.T.GOpi Kumar.

    Monday, March 19, 2007 1:45 PM
  • Thanks very much for your reply! Unfortunately, i am already keeping the ofn struct as private member of the class. I did try switching char to WCHAR and using the text macro on the string tho. No luck =\. I didn't really make this clear (i probably should have) but i'm not using MFC -- not sure if you were, but i would have guessed by the class name. Thanks again!
    Monday, March 19, 2007 8:42 PM
  • You should do what TilakGopi is doing for you; that is, create a small program that reproduces the problem. I think it is unlikely the problem exists in the code you have posted. Therefore if you create a program that uses just just the minimum necessary to use the code you have posted and then you see it works, you will see it is not a bug in the Windows SDK. You can then add more from the main program until you encounter the problem. Then you will have limited the portion of code causing the problem.
    Tuesday, March 20, 2007 12:24 AM
  • I actually do have another program that uses the OPENFILENAME struct and GetOpenFileName, but the code looks different. I have the same problem with it.
    Tuesday, March 20, 2007 3:02 AM
  • I present to you a very simple program using GetOpenFileName that, like the others, crashes at the tooltip of a file in the second open dialog assuming the tooltip was shown in the previous dialog and that the file is on the desktop. 

    =====================================================================
    #include <windows.h>
    void InitOFN(OPENFILENAME &ofn);
    void SetOFN();
    OPENFILENAME ofn;
    int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR, int)
    {
       InitOFN(ofn);
      MSG msg = {0};
      while (msg.message != WM_QUIT)
      {
    if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
    {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
     }
     if (GetAsyncKeyState(VK_RETURN) & 0x8000)
    {
    SetOFN();
    GetOpenFileName(&ofn);
    }
    if (GetAsyncKeyState(VK_ESCAPE) & 0x8000)
    msg.message = WM_QUIT;
    }
    return 0;
    }
    void InitOFN(OPENFILENAME &ofn)
    {
    ZeroMemory(&ofn, sizeof(OPENFILENAME));
    ofn.lStructSize = sizeof(OPENFILENAME);
    ofn.lpstrFilter = "Game Level File\0*.elf\0\0";
    ofn.nFilterIndex = 1;
    ofn.lpstrDefExt = "glf";
    ofn.nMaxFile = MAX_PATH;
    ofn.nMaxFileTitle = MAX_PATH;
    }
    void SetOFN()
    {
    static char path_buf[MAX_PATH];
    static char name_buf[MAX_PATH];
    memset(path_buf, '\0', sizeof(path_buf));
    memset(name_buf, '\0', sizeof(name_buf));
    ofn.lpstrFile = path_buf; // buffer for file name edit control
    ofn.lpstrFileTitle = name_buf; // buffer for file title
    ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;
    }
    Tuesday, March 20, 2007 4:13 AM
  • yxrk,

    Maybe try putting OPENFILENAME, both its structure and functions in the CALLBACK where I think it belongs in the first place. However, if you really need to open up a file in the WinMain() then it would seem to me that it might be a good idea to know the file's name and where it is in the first place. Otherwise, you may be fishing in a lake before it got filled up with water, not to mention fish. And it would be safer to do this before you got into the WinMain()'s while GetMessage(&msg,,,) loop.

    On the other hand, re-doing the WinMain()'s while (GetMessage(&msg,,,,)) loop with PeekMessage(&msg,,,) and such stuff may not be such a hot idea with OPENFILENAME's structure. It’s probably getting hit in the face every other fraction of a second with something from somewhere. If so, then your program's stack might have simply overflowed, which would explain why it has a tendency to crash.

    JamesSexton


     

    Tuesday, March 20, 2007 2:01 PM
  • Hi,

    some how , i am able to get u following messages, when exception occured

    C:\WINDOWS\system32\ntdll.pdb: Cannot find or open the PDB file.
    C:\Documents and Settings\gopi\Desktop\Forum Test Codes\W32Wnds\ntdll.pdb: Cannot find or open the PDB file.
    C:\WINDOWS\symbols\dll\ntdll.pdb: Cannot find or open the PDB file.
    C:\WINDOWS\dll\ntdll.pdb: Cannot find or open the PDB file.
    C:\WINDOWS\ntdll.pdb: Cannot find or open the PDB file.

    Can anybody catch the problem now?

     

    Thanx,

    Ch.T.Gopi Kumar.

    Tuesday, March 20, 2007 3:31 PM
  • Mr. Sextron, my real app has the ofn struct in a class and doesn't look like a hack. Thanks for the reply tho.
    Wednesday, March 21, 2007 7:56 AM
  • I don't think it is your code, I think it is a bug in Windows. I spent hours checking my code. Checked it in Delphi same thing, the code is:

     

    OpenDialog1.Execute;

     

    I get the same problem with Notepad.exe, the windows supplied program. Try creating an empty text file on the desktop. Start notepad by double-clicking the file. Go File|Open double-click the file. Again, go File|Open select the file and wait 10 seconds. For me, notepad crashes sometimes, usually if it doesn't crash "File|Open ...wait... double-click file" 3 times will cause it to crash.

     

    Regards,

    Andrew O

    ps I'm running Windows XP Home Edition SP2

     

    Tuesday, April 03, 2007 11:46 AM
  • yah i think like that but this will not happened in my PC. This will happen when i have to copy my whole project into other machine , compile the project and run it.
    Tuesday, April 03, 2007 1:14 PM
  • yxrkt,

    I'm sorry, I certainly did not want to suggest or imply anything about you or your program.

    I simply intended to say that there might be an easier solution to your application's problems

    by placing OPENFILENAME's structure and GetOpenFile() in your application’s CALLBACK instead

    of its GetMessage() loop.

     

    Why..? Well the answer is very simple because your application's GetMessage() loop is really

    NOT at all very simple, regardless of your program's size. Take this as sound advice from an old

    "hacker" (so to speak) like me who has learned the hard way that a simple solution to problem

     is often far better than complex one.

     

    Good luck to you, yxrkt

    Over and out,

    JamesSexton

    • Proposed as answer by Roger Bowser Saturday, August 23, 2008 12:23 PM
    Thursday, April 05, 2007 4:40 PM
  •  

    I am getting the same exact problem. I have used the GetOpenFileName() in a very simple program directed to it and it still crashes. I also tried calling GetOpenFileName() in CALLBACK and either though the function was called, nothing happens. I currently have my ofn in WinMain, but not the message loop.

     

     So is this a Windows bug?...

    Sunday, October 14, 2007 9:47 AM
  • The original question has been answered; does the answer work for you? If not, then your problem is not the same and you should create a new thread and describe your problem with sample code.
    Sunday, October 14, 2007 5:16 PM
  • I had exactly the same problem and found a solution posted on the net.
    Call CoInitialize(NULL); at the start of your thread and UnCoInitialize(); at the end.  Worked for me.

    See http://www.ureader.com/message/821299.aspx

    Saturday, August 23, 2008 12:25 PM