GetOpenFileName view changed with Win 10

[dboggs]

I have some applications (Quickwin) that use the API function GetOpenFileName, called with a derived-type structure OFN. Up pops a window showing files, matching a filter, for the user to select. The view has always been in the "list" format, in Windows Vista, 7 and 8.1. Since changing to Windows 10, the view is in "icon" format instead. How can I force it to be in list mode?

Looking at some sample code on the net, I am led to believe the OFN structure may contain a member named DialogView or something like that; or, the Flags member may offer a setting called OFN_List or something like that (along with OFN_LargeIcon, OFN_SmallIcon, OFN_Thumbnails, etc.). But I could not comprehend the code sample (nearly 400 lines just to call GetOpenFileName!) and I cannot find documentation of these alleged features.

Can anybody help? Lest I resort to trial and (mostly) error!

[IanH]

I would guess that the format of the files shown would reflect the default format nominated by the user in the explorer shell interface (i.e. as set within an explorer window, Tools > Folder options, View tab, etc).
 

[Steven_L_Intel1]

I concur with Ian - it is using whatever the user has set for a default Explorer view. I do note that Windows 10 tends to reset a lot of defaults on an upgrade.

[dboggs]

Further testing yields results (at least sometimes).

I have tried presetting the View properties in File Explorer, both on the default folder and the folder that my application usually accesses. Had no effect (sorry Ian and Steve).

But duh...the GetOpenFileName window has at the top a "mini ribbon" that has a View options dropdown for user control. I have always ignored this feature because the default View property always seemed to be what I wanted. How this setting got changed to Icons by default is beyond me--apparently just a "new feature" of Windows 10 as Steve suggested. If I use this dropdown to choose List, then that will stick.

That said, since the View setting appears to be a property of GetOpenFileName that the user can select, it seems that a developer should be able to control it programmatically. The code I found on the net may be a white elephant, appearing to use a variable ofn_list to do this. But I can find no other documentation of this, and I cannot make it work.

[IanH]

I can't see anything in the documentation for GetOpenFileName or the OPENFILENAME structure that suggest programmatic control.

It might be permitted by the newer COM based IFileOpenDialog approach.  I have never used this in anger from Fortran, though apparently (based on my posts to this forum) I did try once.  Example code that requires about 40000 lines just to get a filename from the user sounds a lot like a COM approach.

[jimdempseyatthecove]

I haven't tried GetOpenFileName on Windows 10, but if it works similar to the older Windows Explorer, it may have its own viewing preference different from Windows Explorer. If I were to guess how to set the default preference it would be

Programmically call GetOpenFileName with the options that enable the tool bar.
Navigate to the folder of interest.
Set view to details (assuming this is available).
*** Navigate off of that folder
Open some arbitrary file (which may be back in the desired folder)
Take a normal exit of your application.

IOW do not cancel the GetOpenFileName dialog.

It may be the case that the noob writing the MS dialog only uses his phone to browse icons. (much like that stupid banner at the bottom of this page which occults this edit box and Submit button).

Jim Dempsey

[dboggs]

#5: The example code I referred to was 400 lines not 40000. Still way too many.

[JohnNichols]

Bring back DOS 2.1 - get rid of the path and let Microsoft still have Fortran

Dreaming again --

J