Unanswered CFileDialog hangs after clicking Save button.

  • Monday, June 18, 2012 6:39 PM
     
      Has Code

    Hi,

    I have a problem with saving a file using CFileDialog.  If the file doesn't exist, CFileDialog will only return when the Save button is clicked the first time.  After that it hangs when the save button is clicked and will not return from the DoModal unless Cancel is clicked.  It works every time if the file already exists in the folder. Once it quits working, I can go to other parts of the application that save files and the CFileDialog, Save will still hang.  So it isn't even the same routine that is failing - they all fail.

    I'm using C++ VS2008 on Windows 7 (but our executable runs on the Army Gold Lockdown version).  We never saw the problems we're seeing now on XP.  We compile on 64 bit Win7 but we're building a Win32 application - don't know if that contributes to the problem or not.  It always works if I'm running in debug.  My system is up to date on patches and window 7 updates. We import a ton of dll's, and we have do have stack size set (can't run without it) - all things that have been mentioned in prior posts.

    • I set the szFilter parameter every time I call CFileDialog but it's not nested in a loop. 
    • I've appended a null char on all directory/file settings to the m_ofn structure. 
    • I've tried the UpdateOFNFromShellDialog() call right after Create and before I set anything else (as the sample code suggests - I get an exception if I use the ApplyOFNToShellDialog before calling DoModal() - so I dropped that call. 
    • I've even tried calling the CFileDialog with no parameters (FALSE) with no luck. 
    • I've tried making the dlg a pointer and deleting it when done. 
    • I've tried setting the m_ofn information without using the GetOFN() method.  All with the same results - it hangs when the Save button is clicked.
    • I've  tried making my own CFileDialog class, with the same results.
    • Furthermore, if I make changes, recompile and put the executable in my test environment it will work initially but if I reboot it does the works-once-hang thing again. 

    I understand the underlying Shell is different in Windows 7 but I just can't figure out what is going on.  This is pretty simple stuff and my code is pretty much the same as the sample C++ code in the CFileDialog class information.  Here is a snippet of the code:

          CString     displayFileName, title, folderPath, path, fileName;
    
          TCHAR szFilter[]= _T("Comma Separated (*.csv)|*.csv|Excel Workbook (*.xls)|*.xls||");
    
     
    
          displayFileName = "ReportName.csv";
    
          title = "Save Report to File";
    
          CFileDialog  dlg = CFileDialog(FALSE, ".xls", displayFileName,                             
    
                                                          OFN_OVERWRITEPROMPT, szFilter, this);
    
          dlg.UpdateOFNFromShellDialog();
          dlg.GetOFN().lpstrTitle = (LPTSTR)(LPCTSTR)title+'\0';
          dlg.GetOFN().lpstrInitialDir = (LPTSTR)(LPCTSTR)DataFolder+'\0';
    
          if (dlg.DoModal() == IDOK) {
                folderPath = dlg.GetFolderPath();
                path = dlg.GetPathName();
                fileName = dlg.GetFileName();
          }
    
    

    I would appreciate any direction that someone can give me.  Thanks in advance!

    Katharine

     

All Replies

  • Tuesday, June 19, 2012 4:36 AM
     
      Has Code

    There are a lot strange things in your source code.Here only an example:

    Why the additional zero termination

          dlg.GetOFN().lpstrTitle = (LPTSTR)(LPCTSTR)title+'\0';
          dlg.GetOFN().lpstrInitialDir = (LPTSTR)(LPCTSTR)DataFolder+'\0';

    After your DoModal you made something wrong when you are using "GetFolderPath". It is not allowed to use this function whne the dialog is not open.

    http://msdn.microsoft.com/de-de/library/xz5y6xhy%28v=vs.80%29.aspx

    Quotation from this help topic:

    You can call this method only while the dialog box is being displayed. After the dialog box has been closed, this function will no longer work, and the method will fail with an assertion.

  • Tuesday, June 19, 2012 2:11 PM
     
     

    Bordon,

    Thanks for your response.

    Actually my code was relatively simple before I started having problems.  It has gotten worse in trying to "fix" it.  I think I'll go back to the original and start again.  I didn't append null chars before but I changed it because of the notes on this page (it made no difference): 

    http://msdn.microsoft.com/en-us/library/ms646960%28v=vs.90%29

    Good eyes on the GetFolderPath():  I see now that the call to GetFolderPath() is an error (and wasn't even used!) but in other places in my application where there is no call to GetFolderPath(), it still fails.  When I test the app though, I usually try this area of code first.  So maybe the fact that having the GetFolderPath() erroneously being in my first test case causes problems further down the line.

    Regards,

    Katharine

  • Tuesday, June 19, 2012 7:29 PM
     
     

    In your Post first thing you never checked the value of dlg . Second thing are you using thread inside your application or what " I can go to other parts of the application that save files and the CFileDialog, Save will still hang" I am confused by this message .When it hang how can you got to some other part of the application. What is this DataFolder inside your code. Remove all NULL as mentioned by Bordon.I am not able to see anything wrong here .GetFolderPath() condition is fine because It will come in the picture when dialog will get terminate Due to DOModal==ID_OK. Check out lpstrInitialDir etc. Or comment them for the time being and try once again.

    Thanks


    Rupesh Shukla


  • Wednesday, June 20, 2012 4:18 PM
     
     

    Rupesh,

    Thanks for the response.  I have removed the null characters and the call to GetFolderPath().  By hanging, I meant that I can't get out of CFileDialog DoModal() unless I click the Cancel button - clicking the Save button does nothing - it just sits there - unless the file name exists in the folder or it's the first time that CFileDialog DoModal() was called.

    I think our problem may be related to the version of the OS that we are using.  As I mentioned in my original post, our test environment is the Army Golden Master version of Windows 7.  It's a "locked-down" version of Windows 7 with some features disabled and restricted user accounts.  We have opened up permissions on the folders where the users are saving files.

    With the changes that I've made, in our test environment and after a fresh installation of the AGM Win7 OS, it appears to be working.  Maybe the GetFolderPath() was causing some unintended consequences in subsequent calls to CFileDialog?

    Thanks again for your input.

    Katharine





     


  • Wednesday, June 20, 2012 6:07 PM
     
     

    Let me rephrase my sentence if you are able to do it once it should work second time too . Second When you open a dialog to save file and you don't have any valid file name under save as what you expect this is the same behaviour as you can verify it with window file open dialog . Why not perform same operation with window File open dialog and perform a comparision . And let us know the result . Second is you don't have a valid file name only cancel is going to close the file open dialog and due to domodal() condition that make a sense too .

    Thanks


    Rupesh Shukla

  • Thursday, June 21, 2012 3:17 PM
     
     

    I agree that if you're able to do it once, it should work the second time.  That is not what happened though.  If it had been correct the second, third, fourth... time, I wouldn't have had a problem. 

    I did try comparing the open file to the save file in early attempts to discover the problem.  The open file dialog works, every time.  For the Save file, the file name was correct, had a valid extension and no invalid characters. 

    As I mentioned above, I still believe that at least part of the problem may be with the Army Golden Master secure version of Windows 7 OS, which is our test environment OS. 

    Thanks again,

    Katharine

     
  • Wednesday, June 27, 2012 7:40 AM
    Moderator
     
     

    Hello,

    I'm very interested in hearing more about your issue, did you solve your problem?
    If yes, please mark the answers and close the post; If not, please feel free to post your doubt.
    Thanks for your active participation in the MSDN Forum.

    Regards,
    Elegentin


    Elegentin Xie [MSFT]
    MSDN Community Support | Feedback to us