In my recent posts I’ve discussed the .NET FolderBrowserDialog and how to improve upon it with an extended variant that supports more of the SHBrowseForFolder API’s capabilities.

IFileDialog

As it turns out, I am depressingly out of date in terms of my Win32API understanding. And I no longer have the excuse I did ten years ago when I would say that I can’t really use all these newfangled Windows XP features since I was using Windows 98SE at the time, which is equally depressing to think about. Best not to do so. Point is, as it turns out, SHBrowseForFolder is ancient history. Windows 95. Just forget about it. Instead, Starting with Windows Vista, we get the Common Item Dialog. A dialog interface which effectively replaces SHBrowseForFolder, GetOpenFileName, and GetSaveFileName.

The Problem

The problem is, of course, using it. As far as I can tell, there is no IFileDialog implementation within the .NET Framework itself. OpenFileDialog and SaveFileDialog use the GetOpenFilename and GetSaveFilename functions respectively, and FolderBrowseDialog uses SHBrowseForFolder. It seems a curious omission. As it turns out, the Windows API Code pack does implement support for the Common Item Dialog. But that leaves us in the position to make a decision- do we use the Code pack, which appears to be abandoned, or do we create our own wrapper, and deal with maintaining it.

Looking at the details on MSDN, I think using the existing API Framework is a better approach. The biggest caveat is finding it. The binaries are available as NuGet Packages, but toe original links were taken down. This is a major shame and I really don’t understand why this is being done. I get that the new Modern UI-style and web-like approach is being pushed even for local applications (I find it silly to throw away several decades of desktop UI development…) but it makes no sense to try to erase this sort of stuff from existence. The Win32 API is not going to be replaced entirely and I’ve found the current “replacements” to be limited and mostly suited well for mobile application development. I shouldn’t need to go to a “FileStore” to save information locally. But I Digress into a pointless rant. Thankfully, the API Code Pack for Windows 7’s strange disappearance was picked up already by other, more observant bloggers which have provided useful mirrors for the original source packages, as well as several github appearances.

Supporting multiple platforms

While the development industry is constantly moving forward, those of us who actually support real-life customers don’t have the luxury of telling our clients to upgrade their 100+ machines to the latest Windows Operating System just to use our software. Instead, we need to write software that works on what they have. Sometimes this can mean writing QBASIC code in MS-DOS for a controller; sometimes this can mean writing THEOS BASIC for THEOS Corona. Windows XP is out-of-date but compared to the other two it’s a spring chicken, so count your blessings. But this does raise the issue, in code, especially when you want to utilize new features, of allowing your program to degrade gracefully on older systems.

For folder browsing, that solution seems straightforward- if we are running a supported platform, use the Common File Dialog for folder selection. Otherwise, we can use the FolderBrowseDialogEx class (or the .NET Class) to provide folder browsing capability.

This allows you to use a single Function that will use the method appropriate to the platform it is run on. The Folder browsing is straightforward, thankfully- as there is an older analog. This would get far more complicated when you involve things such as the TaskDialog- the only equivalent for pre-Vista systems was effectively the Messagebox which could involve different semantics from a UI standpoint, as it cannot provide as much information or capability.