Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

CommonDialog Issue

CommonDialog Issue

CommonDialog Issue

Since the recent update to Windows 10, version 22H2, we are having random problems with the CommonDialog control. Sometimes it takes five or more seconds to return a file path - creating user havoc...

I know that there are alternatives to the CommonDialog control, but somehow I just can't think of one that has similar functionality - need something more robust than GetFile().

RE: CommonDialog Issue

Are you able to get it faster on the same clients when you deinstall the upgrade?

The most direct reason for a slower file dialog is a HDD that's broken, or its controller. With SSDs you could try to get performaceup with TRIM. Before you do that just as a guess, I'd check the HDD health status with an S.M.A.R.T. tool https://en.wikipedia.org/wiki/S.M.A.R.T.

A simple test whether it is the drive would be adding an external USB drive that can be addressed faster. If a new drive also reacts slow to the common dialog you have some confirmation, but now you might just have coincidence, which I often get from customers that can only think of Windows Updates as the last thing that changed their system and just don't know about other changes pushed to their clients by adminstration or forgot that they actually introduced something else themselves.

In my experience slow hard drive actions usually are pointing out a degrading hdd, no more, no less. It's also the most natural reason.

What on earth should make a dialog slow, that is a Window, the thing that is the root of the OS name, just because there was any upgrade? It's such a common and central thing, not only creating windows/forms, but also addressing the file system, that I'm eager to say that would not havve passed Microsoft testing. Even though common dialogs are an old technology, it's still a common part of Windows.

Are you using the core Windows API, or are you perhaps using a third part OCX that makes using Common Dialogs easier? You could easiy convince me that an OCX became slower since a Windows Upgrade, as I have seen OCXes degrade (though they did not become broken) when they get old and use something that depracates. Especially when they are programmed to switching to a fallback after a timeout. That could even be something as funny as a dependency with a specific font that got removed. So one other thing you should try in that case is more direct usage of the common dialogs.


RE: CommonDialog Issue

I recently posted this, which actually makes use of the OLE interface:


Define Class multiselectForm As Form
   Add Object commonDialog As OleControl With OleClass="MSComDlg.CommonDialog"

That should work it's nothing third party, it's MS. See thread184-1819275: Select multiple files in VFP for the full code sample.

You can also more directly use the GetOPenFileName API function: https://learn.microsoft.com/en-us/windows/win32/ap...
Which you declare in VFP as:


Declare Integer GetOpenFileName in comdlg32.dll STRING @ FILEOPENSTRUCT 
So far, so easy, yet the struct - as always - is morecomplicated to build up. It does not cotnain the file name skeleton, for example, but a pointer, an address to it, so on top of creating the struct you also have to allocate memory and store strings there to know the address you can put into the struct.

I don't speak Russian, the VFP code part should work, though. I haven't tested it, but it looks complete.

The obvious other solution is roll your own, using ADIR, for example and displaying file names in a listbox or grid for selection, as Mike already suggested, besides that odd looking listbox with RowSourceType 7. It's not worth using, but it's fast to implement as alternative to check whether it's really the dialog that slowed down or the drive. Likewise GetFile, though you don't like it. If all these ways became slow it's most probably the drive. Or the directory has very many files. My Downloads system folder also lists way slower than other ddirectories (about 5 seconds), just because it has 339 elements.


RE: CommonDialog Issue

Hi Chris,

After the complaints, I reproduced the issue on two Dell laptops. Ran SFC and the DISMs, checked memory, SSD and M.2 drives, uninstalled the KBs. There were no issues. The strange thing is that the 5 second delay is random and only occurs about 85% of the time. We are using "MSComDlg.CommonDialog" like you showed above. I do like the "GetOpenFileName" API that you provided a link to - I was looking at that API yesterday, but was scratching my head on the structure. So, thanks for that link - I think that is the best way to go as it is just as flexible as MSComDlg.CommonDialog. And it's always good to get rid of another problematic ActiveX control.


RE: CommonDialog Issue

Thanks, that looks also like a clean usage of the API function.

I wonder if it will differ in behavior, it will be the same Window class, just not using the MSComDlg.CommonDialog OLE layer. If its really the dialog it should remain problematic, but it would be good to know the OLE helper class is causing trouble.


RE: CommonDialog Issue

As far as I tried the code you pointed out from VFPX github, the dialog has a longer delay at first usage for me, could be 5 seconds.

If run multiple times it comes up fast, though I can measure a noticeable delay time before the dialog appears, which I can do by putting ESC in the keyboard buffer right before starting the dialog, so it exits with CANCEL right when it appears.

The delay is about half a second, noticeable, but not 5 seconds. Using high precision timers I could determine it with higher precision *sigh*, surely, but for a span in the range of half a second the values of SECONDS() before and after are good enough.

And this delay also happens using the MSComDlg.CommonDialog helper class. I think there is no difference, because this OLE class is not the visual class that is the dialog, it's just a helper that has properties it puts together as the struct the API call needs and in the end you get exactly the same, without needing to do all the memory allocations and deallocations. Potentially the Olecontrol could be a whole window, I know, it's the concept of OLE controls, but the multiselectForm form class is started and never shown. Even if it would be you would expect to see a dialog window within a VFP form, and you don't.

I'm curious what behavior you'll see, especially if things remain having about 5 seconds delay in 15% of the cases.


RE: CommonDialog Issue

I did one more comparison with a VFP form that has nothing but a button with Cancel=.T. called with ESC. The duraton from create to close is only about 0.04 seconds, far shorter.

I can see how that half second delay of the common file open dialog is normal and healthy if the first step is getting directory information and preparing the form with it before displaying. It would also explain a first time delay that's due to "waking up" if it's still legacy style platter hard drives.


RE: CommonDialog Issue

Last comparison:


Keyboard '{ESC}' Plain
Gives about 0.4-0.5 seconds. That should be the acceptable delay time needed to get directory information.


RE: CommonDialog Issue

The problem mysteriously disappeared this morning. Ran AV scans on both test laptops on Saturday with no issues - problem still persisted. No change on Sunday. Today, the problem vanished like a fart in the wind. Maybe Widows updates are now in some sort of AI mode...

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close