CFileDialog problems on Win2000 with read only files
-
I have run across a problem using CfileDialog on Windows 2000 for which I have not yet found a solution. The problem is as follows: If I instantiate an instance of a CFileDialog passing TRUE as the first parameter and accepting the default values for all other parameters, and then call DoModal(..) on the object, then the standard CFileDialog is displayed. However, if I navigate to any folder that contains a read-only files, then I hit a user breakpoint deep within NTDLL. To see this problem, the simplest possible reproduction is to create a dialog based MFC app that uses CFileDialog as its main window. I had thought that specifying the OFN_DONTADDTORECENT flag might fix this problem but it did not. I also tried getting rid of the OFN_HIDEREADONLY flag, but that had no effect either. Once the breakpoint is called in NTDLL, you can step over it to receive a 2nd which can be stepped over as well, and then the program continues normally until you shut it down at which point 2 additional breakpoints are encountered. Of course, in release mode, the operation is seamless and no problems are evident. I have not been able to find anything at MSDN online that gives a description of the problem or a work around. If anyone has any information on a workaround that will keep Win2000 from hitting this internal breakpoint, I would appreciate it
-
I have run across a problem using CfileDialog on Windows 2000 for which I have not yet found a solution. The problem is as follows: If I instantiate an instance of a CFileDialog passing TRUE as the first parameter and accepting the default values for all other parameters, and then call DoModal(..) on the object, then the standard CFileDialog is displayed. However, if I navigate to any folder that contains a read-only files, then I hit a user breakpoint deep within NTDLL. To see this problem, the simplest possible reproduction is to create a dialog based MFC app that uses CFileDialog as its main window. I had thought that specifying the OFN_DONTADDTORECENT flag might fix this problem but it did not. I also tried getting rid of the OFN_HIDEREADONLY flag, but that had no effect either. Once the breakpoint is called in NTDLL, you can step over it to receive a 2nd which can be stepped over as well, and then the program continues normally until you shut it down at which point 2 additional breakpoints are encountered. Of course, in release mode, the operation is seamless and no problems are evident. I have not been able to find anything at MSDN online that gives a description of the problem or a work around. If anyone has any information on a workaround that will keep Win2000 from hitting this internal breakpoint, I would appreciate it
Sorry that this is not a answer to your problem, but I tried creating a dialog app using CFileDialog as the main window. It worked fine in debug mode on read-only files. The only thing I can say is I have Windows 2000 Professional with SR-1 and DevStudio 6.0 with SR-4. Sorry I can't help, Jonathan Craig