CommonDialog Issue

[vernpace]

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().

 

[Chris Miller]

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.

Chriss

 

[Chris Miller]

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"
Enddefine

That should work it's nothing third party, it's MS. See thread184-1819275 for the full code sample.

You can also more directly use the GetOPenFileName API function:

https://learn.microsoft.com/en-us/windows/win32/api/commdlg/nf-commdlg-getopenfilenamea

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.

https://forum.foxclub.ru/read.php?29,353377,354098

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.

Chriss

 

[vernpace]

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.

Jeff

 

[vernpace]

Here is another similar solution from Anatoliy Mogylevets:

https://github.com/VFPX/Win32API/blob/master/samples/sample_363.md

 

[Chris Miller]

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.

Chriss

 

[Chris Miller]

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.

Chriss

 

[Chris Miller]

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.

Chriss

 

[Chris Miller]

Last comparison:

s=Seconds()
Keyboard '{ESC}' Plain
GetFile()
?Seconds()-s

Gives about 0.4-0.5 seconds. That should be the acceptable delay time needed to get directory information.


Chriss

 

[vernpace]

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...

 

[Chris Miller]

This should wwork:

https://github.com/VFPX/Win32API/blob/master/samples/sample_363.md

Chriss