| |
|
|
|
|
|
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.
|
Subject |
Author |
Date |
|
|
Evgueni Kolossov
|
Mar 17, 2011 - 3:01 AM
|
All CExtShell dialogs are extremely slow in comparison with standard dialogs. This is not acceptable to wait over 5 seconds for dialog to appear. Please suggest the way to accelerate dialogs load
|
|
|
Evgueni Kolossov
|
Mar 18, 2011 - 9:09 AM
|
1) and 2) is not the case, 3 - questionable and standard dialog is not slow. So, this is definitely a bug you need to fix ASAP. In current way it working it is not acceptable at all
|
|
|
Technical Support
|
Mar 17, 2011 - 9:34 AM
|
This is a known issue:
1) Sometimes it occurs on a computer where a diskette drive is present. Shell APIs are slow on particular computers with diskette drives. This issue is not resolved yet.
2) A folder contains 5000 files or more. Current version of shell controls scan all files at once. Background scanning is not supported. Please use file type filters to reduce the number of displayed shell items.
3) Particular network paths pointing to particular computers work extremely slow. But this is typically the same for Windows shell dialogs.
|
|
|
Jeroen Walter
|
Mar 25, 2011 - 6:11 AM
|
2) ... Why should we implement this questionable workaround ? Seems to me that you background processing of the files can address all problems.
It would be nice to have shell dialogs in the chosen skin of the application, but if you can’t or won’t fix them, why bother supplying them at all?
|
|
|
Evgueni Kolossov
|
Mar 18, 2011 - 9:10 AM
|
1) and 2) is not the case, 3 - questionable and standard dialog is not slow. So, this is definitely a bug you need to fix ASAP. In current way it working it is not acceptable at all
|
|
|
Lars Mohr
|
Mar 17, 2011 - 2:38 PM
|
concerning 3: But the standard Windows shell dialog does not block the whole application.
|
|