I'd like to re-open this conversation with a modified version of this request -- I've been fighting the common dialog battle for a while. It is possible to subclass the common dialog box at the time that it's created, and then intercept select components of the dialog box and make them invisible, or change their class to a read-only style. For example, the standard 2008/2012 common dialog box allows you to type any old thing you want in the top section, like 'cmd.exe'. And, if you aren't using AppLocker to restrict cmd.exe from running, your user's can quickly and easily get to a command prompt. This of course opens up a whole can of worms because windows runs your login script with cmd.exe so that gets blocked as well. In a terminal server environment this becomes a big problem.
I've heard of enterprise-level solutions to "locking down" the common dialog box, but they also come with enterprise-level pricing which is impossible for a small company like ours to justify. For our in-house applications, the only solution I had was to subclass the common dialog box each and every time I used it in code, which is a management nightmare. But, it works.
Here's a 'standard' common dialog box raised by the application without subclassing --
Here is the same dialog after my code intercepts the call to the common dialog, subclasses the form, and then "hides" some of the naughty features --
This is an extremely low tech solution to the problem. However, there is no solution for other applications whose source code I don't have (like 'notepad.exe').
Some options that I think could be implemented by some program that already has the ability to hook into shell level actions (*cough* classicshell *cough*) would be --
- Hide Common Dialog Nav Box
- Hide Common Dialog Tool Bar
- Hide Common Dialog Network Places Frame (OFN_EX_NOPLACESBAR)
- Force downgrade to XP-Style dialog box (OFN_EXPLORER, OFN_NONETWORKBUTTON)
Print dialog also has issues that can be intercepted with a subclass
- PD_NONETWORKBUTTON
- PD_DISABLEPRINTTOFILE
- PD_HIDEPRINTTOFILE
Note that OS versions prior to 2008 also had the following commondialog options which are no longer respected by Microsoft
- Software\Microsoft\Windows\CurrentVersion\Policies\Comdlg32\NoComputersNearMe
- Software\Microsoft\Windows\CurrentVersion\Policies\Comdlg32\NoEntireNetwork
- Software\Microsoft\Windows\CurrentVersion\Policies\Comdlg32\NoNetHood
- Software\Microsoft\Windows\CurrentVersion\Policies\Comdlg32\NoRecentDocsNetHood
- Software\Microsoft\Windows\CurrentVersion\Policies\Comdlg32\NoStartMenuNetworkPlaces
I don't think a system wide "replacement" of the common dialog box is feasible for all the reasons mentioned in the FAQ. There are just too many combinations, and the common dialog api exposes different functionality based on the "size" the structure passed to it, for backwards compatibility. The combinations are endless. But within a narrow set of parameters I think its possible to target specific graphical elements on the form at the time the dialog is created, and then use some windows messaging to hide them. I personally don't have the platform or the means to try and build my own system wide solution to the problem but I'd gladly work with anyone who wanted to try and tackle this at the system wide level.
Thanks for listening!
Ron