Introduction

ShellBrowserControls is a collection of ActiveX controls that can extend some of my other controls (e. g. ExplorerListView and ExplorerTreeView) by shell-browsing functionality. It is optimized for Visual Basic 6.0, but should also work in any other environment that supports COM controls.

Basics

The controls can be attached to instances of ExplorerListView and ExplorerTreeView to enhance them with shell-browsing capabilities. All the complicated things like enumerating shell namespaces, providing and handling shell context menus, drag'n'drop, extracting thumbnails, reacting automatically to changes within the shell and many other things are done by ShellBrowserControls in a highly optimized (e. g. by using parallelization) way. While ShellBrowserControls will take over as much work as it can by default, the client application can decide very precisely which tasks are done by ShellBrowserControls and which are done by the application itself.
While I implemented more checks and error handling than I have done in any other control before, this is also the most complex control library that I ever wrote. Shell programming is a very challenging task and Microsoft does anything to keep it like this, e. g. by not documenting things, documenting things wrong and implementing things in a very Windows Explorer specific way. So applications that use this library should be tested really well, especially with different versions of Windows.

Requirements

ShellBrowserControls Unicode runs on the following operating systems:

Windows XP (SP3 or later)
Windows Server 2003 (SP2 or later)
Windows Vista (SP2 or later)
Windows Server 2008 (SP2 or later)
Windows 7 (SP1 or later)
Windows Server 2008 R2 (SP1 or later)
Windows 8
Windows Server 2012
Windows 8.1
Windows Server 2012 R2
Windows 10
Windows Server 2016
Systems supported by Wine (Wine is a Win32 subsystem for alternative operating systems) - limited support
ReactOS (a free Windows 2000 clone) - limited support

The files shlwapi.dll and shell32.dll must have version 5.0 or later.
Some features have additional requirements which are mentioned in the affected feature's documentation.
Limited support means, that I won't invest much work to support those systems. If a feature works on a system marked with "limited support" - fine; if it does not and it's easy to fix, I'll fix it, but if it's difficult to fix, I probably won't fix it. Also I will test the control much less on those systems.

Support

There's no entitlement to support. Period. However, you have good chances to get help if you post your questions on GitHub or in the forums.
Also the project is open source, so feel free to have a look at the source code. You may modify it, but please consider sharing your changes with the rest of the world.

License

     MIT License

     Copyright (c) 2010-2018 Timo Kunze

     Permission is hereby granted, free of charge, to any person obtaining a copy
     of this software and associated documentation files (the "Software"), to deal
     in the Software without restriction, including without limitation the rights
     to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
     copies of the Software, and to permit persons to whom the Software is
     furnished to do so, subject to the following conditions:

     The above copyright notice and this permission notice shall be included in all
     copies or substantial portions of the Software.

     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
     IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
     FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
     AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
     LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
     OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
     SOFTWARE.

Acknowledgements

Thanks go to:

Henk Devos, because without his work and insider infos, I wouldn't have the knowledge about Windows Shell programming that I have.
Nikos Bozinis, for inspiration and his awesome help especially with the Vista drag'n'drop stuff.
Jim Kueneman, for much help on tricky shell stuff, for inspiration and motivation.
Jim Barry, for much help on tricky shell stuff, especially thumbnail support.
Geoff Chappell, for his website about undocumented Win32 API stuff.
Wine Headquarters, because Wine helped me a lot on understanding how Windows is working.
Microsoft, for ATL, WTL and Visual Studio - great libraries and a great IDE
Igor Tandetnik, for his great help on learning ATL and WTL
Dimitri van Heesch, for Doxygen
Christian Lütgens, for his great work as beta-tester and for his help when I needed a 2nd opinion on some decisions.
All donators
For great music: Heaven Shall Burn, Arch Enemy, Machine Head, Trivium, Deadlock, Draconian, Soulfly, Delain, Lacuna Coil, Ensiferum, Epica, Sirenia, Tristania, Nightwish, Battlelore, Amon Amarth, Volbeat, Guns N' Roses

No thanks go to:

The persons at Microsoft responsible for documentation - If a part of the non-managed API is documented, one can bet that the article is either an unsubstantial one-liner, an article full of failures or an article that doesn't cover the most important parts.
The persons at Microsoft that don't care whether important features of the common controls and the shell are useable by 3rd party software. First you scare skilled developers away, then the users follow due to the lack of good software. Think about it.

FAQ

1. Why is event xyz not fired?
Firing an event is relative time-consuming, even if the event isn't handled by the application at all. Therefore I implemented a DisabledEvents property which can be used to deactivate certain events.
By default many events are deactivated.