Forum

Hi!

I made a simple example using the CExtShellDialogFile

void CTestProfUISView::OnFileOpen ()

{

    CString strPathName;



    CExtShellDialogFile dlgShellFile (NULL, CExtShellDialogFile::__EFDT_OPEN_SINGLE);

    dlgShellFile.m_comboFileTypes.SetFilter(

        _T("Bitmap files (*.bmp)|*.bmp|")

        _T("All files (*.*)|*.*|")

        _T("|")

        );

    dlgShellFile.m_nInitialFileTypeIndex = 0;

    dlgShellFile.m_bFilesMustExist = true;

    if( dlgShellFile.DoModal() != IDOK )

        return;

    ASSERT( dlgShellFile.m_arrRetValNames.GetSize() == 1 );

    strPathName = LPCTSTR(dlgShellFile.m_arrRetValNames[0]);

}

On some PC’s ist working perfectly but on some the application goes to not responding for about 4 Minutes when pressing the Open or Cancel Button.

Then I build the BitmapEditor-u.exe and now it gets crazy :-(

on some PC’s my Example is working and the Bitmap Editor goes to not responding and on others the Bitmap Editor is working and my Example goes to not responding.

The PC’s I used for the test are 3 IPC’s with Win7 Pro 32 Bit SP1 E8500 3.16GHZ 2GB Ram -> different results even on these 3 PC’s.

One DELL Precision M6500 Win7 Pro 64Bit SP1 X920 2.0GHz 8GB Ram

One DELL Optiplex 745 Win7 Enterprise 32 Bit SP1 6600 2.4GHz 2GB Ram

All Pc’s are up to date Feb 19.2012

Different results I get also when I run the examples from a local drive or a network drive.

The BitmapEditor and my Example are compiled with VS2010 Unicode Dynamic Link to MFC this is what we use for all of our applications.

Do you have any Idea how we can resolve this massive Bug?

Best Regards

Walter

Hi!



When I put in the following Sleep() Statements then the Open and Cancel Buttons of the CExtShellDialogFile dialog are working. That means, after the dialog is closed, I can immediatly reopen the dialog.



But that’s not a solution it’s only the evidence that someting is completely wrong!



ExtControlShell.cpp Line 461



        _SL.Unlock();

        _SLTP.Unlock();



        Sleep (50);    // Inserted this Sleep



        ::WaitForSingleObject( hThread, INFINITE );



ExtControlShell.cpp Line 472



        _SL.Unlock();

        _SLTP.Unlock();



        Sleep (50);    // Inserted this Sleep



        ::WaitForSingleObject( m_eventResponse, INFINITE );





But when closing the application it hangs in crtexe.c on Line 568 for at least 2 minutes.



I will not investigate this problem. I think this is your job!



Best Regards

Walter

You put Sleep(50) into the thread procedure which watches folder modifications and lets shell controls to update their lists of displayed shell items automatically. If the Sleep(50) affects the behavior of shell controls in your app, you simply opened the shell file dialog in a folder which contains frequently updated content.

Hi!

Your answer does not fit to my Problem.

At least the 3 IPC’s (Industrial PC’s) have no Network Connections, no Printer, no A: or B: diskette drivers and there was no CD in the CD Drive. The only thing they have is a C: and D: wich are partitions on the local HD.

- This 3 PC’s have the same Hardware, Win7 Pro 32 Bit

1. IPC BitmapEditor is working correct, my TestProf-UIS is not responding

2. IPC BitmapEditor and my TestProf-UIS working correct

3. IPC BitmapEditor is not responding, my TestProf-UIS is working

Then I made a Test on my Office PC with 7 network connected drives and 2 Network Printers. BitmapEditor and my TestProf-UIS working correct.

The CExtShellFileDialog is not responding after I pressed the Open or Cancel Button on the CExtShellFileDialog and NOT when I open the Dialog!

So I dont think its a problem with with the shell enumerations. For me it looks like a thread synchronsiation problem that would explain the different results on PC’s with the same Hardware.

Best Regards

Walter

Shell controls need to enumerate some count of shell namespace items during initialization. Local file system always enumerated very fast. But if your PC have diskette drive or A: and/or B: drives without physical diskette drives, then shell enumerations is much slower. The same is related to CD/DVD drives with bad disk inside. The network part of shell namespace and mapped to network drives (especially unavailable) are always much slower than file systems. Network part of shell namespace can be enumerated faster if network discovery is enabled on your PCs. Finally, believe or not, printing settings can simply kill performance of MFC app. If the default printer is a network printer and it’s unavailable or network connection to it poor, then say goodbye to performance.