Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » CExtShellDialogFile Collapse All
Subject Author Date
Lars Mohr Jan 25, 2010 - 4:14 AM

Hello Support-Team,


I have a question concerning the CExtShellDialogFile class. Why is there a scan on floppy disk if I select the item "My Computer"? And if the last open file was over the network and I restart the programm again and open the dialog it will take up to 5 minutes to open the dialog.


Regards.


 

Technical Support Feb 8, 2010 - 12:56 PM

No, we are trying to re-design shell classes and make them 100% thread independent. You know, most of MFC classes (all the CObject-derived) must be used only in one thread where they are created. Besides, each PIDL in one thread will need to create a cloned copy of it for providing to other thread. This requires serious changes in shell classes.

Lars Mohr Jan 25, 2010 - 3:52 PM

About the scan of A:\ and B:\ drives does not disturb me but the long delay if the dialog has opend a network file before (after restart) is a big problem for me because our customer means the program is hunging up (no response message from MS). Is there a chance to disable the scanning of all sublevel in a network? I think this would reduce the delay. But I agree to you this is only by restart the program and if the last access was a network folder or file.

Technical Support Jan 25, 2010 - 1:54 PM

The shell controls use the standard shell APIs for scanning the shell tree. We just traversing through shell items and querying their properties. We do not perform any tricks. The Windows Explorer and common file dialog definitively use some tricks. We suspect they do not query any properties of A:\ and B:\ drives. We suspect they scan only one item in each sub-folder level (network or local) before scanning other folders on each sublevel in a background thread. The current version of Prof-UIS shell controls uses some basic and simple shell access algorithms without any tricks and multithreading. The performance of scanning A:\ and network paths is really different in each particular case on different computers. It can be fast. It’s not always slow. It’s typically enough close to Windows shell. Some network path can be opened slow in the Prof-UIS shell file dialog. But the same network path is typically opened fast when you invoke the same file dialog for the second time and without restarting your application. Such surprises can be avoided only by pre-scanning the shell tree in the background. We also suspect Windows Explorer does such trick.
We can experimentally put some Windows Explorer like tricks into Prof-UIS shell controls, but this may change class APIs and make them more difficult to use.

Lars Mohr Feb 5, 2010 - 4:26 AM

Are there already results?