Re: CFileDialog + Caching
Hi David,
Even Explorer can be really slow when filling the list control side with
files from a folder that contains thousands of files. I've had it take up
to 3 minutes to open a folder of 100K files. You'd kind of expect handling
of the files to be a little slow and fortunately not a lot of people keep
that many files in one folder. I've had to do testing with drag and drop of
thousands of files as well. I finally addressed the problem using a
progress dialog that allows the user to cancel the operation if they just
don't want to wait any longer (on drag and drop operation).
I think that's just the way it works. Another annoying thing is traversing
to network shares that are not on line. They take a lot of time to
"timeout", but that's just how it goes.
Tom
"David Ching" <dc@remove-this.dcsoft.com> wrote in message
news:qwaci.19201$C96.12035@newssvr23.news.prodigy.net...
"Chris" <Chris@discussions.microsoft.com> wrote in message
news:B7516263-5737-4EFB-A31E-F9E3664C708F@microsoft.com...
Hi. I already use the standard file open dialog (I wrote my own
Filedialog
which extends the CFileDialog), but every time I traverse into that
specific
folder it takes some seconds before the files are listed, should the
CFileDialog do the caching for me? cu chris
Hmm, I would think so. What happens if you show a standard CFileDialog
(just for testing) instead? Does it still takes that long to show the
files? What happens if you navigate to this folder in Explorer? Does
that take a long time also?
You may also want to try to replace CFileDialog with simply calling
GetOpenFileName(). It's simple and avoids MFC hooking the dialog, which
there's an outside chance it's doing incorrectly. In addition, the Flags
field of the OPENFILENAME struct has some interesting fields such as
OFN_ENABLEINCLUDENOTIFY.
Good luck,
David