I’ve fixed a couple of tiny, drag’n’drop related bugs in ExplorerListView and ExplorerTreeView.
I’ve released a new version of ExplorerTreeView 1.x. It fixes an auto-update bug that occured under rare circumstances.
I’ve released the following controls:
- DateTimeControls 1.3.0
- EditControls 1.7.0
- ExplorerListView 1.3.0
- ExplorerTreeView 2.2.0
- TabStrip 1.5.0
- TrackBar 1.5.0
The DateTimeControls, EditControls and the TrackBar control have got the new DetectDoubleClicks property. For some controls, for instance for the Calendar control, Windows does not detect double mouse clicks. I wanted to provide DblClick events, so I worked around this limitation. Unfortunately the Microsoft developers had good reasons to not detect double-clicks for some controls. For instance if you rapidly click on the navigation arrows of the calendar control, you want the months fly by rapidly, but with double clicks enabled, the app will run into double clicks every now and then, and this slows down navigation alot. So I decided to implement a new property which can be used to deactivate my work-around. Attention: For the Calendar control and the up-down part of the UpDownTextBox control, double-clicks now are disabled by default. If you use the DblClick events of those controls, make sure to change the DetectDoubleClicks property to True.
The TabStrip control now can attach a window (usually a control) with a tab and show/hide this window depending on the tab selection. This should make it a bit easier to display different controls on each tab. For instance the attached window could be a Frame control (without border and caption) that contains a specific tab’s child controls. Selecting the tab would make the Frame control (and its content) visible; unselecting the tab would make the Frame control invisible.
ExplorerListView and ExplorerTreeView come with new sorting capabilities. There are new sort criterions which are based on the item text (just like sobText), but treat the texts as integer values, floating point values, currency values or date/time values. Your items are named “1”, “10” and “2” and you want them to be sorted “1”-“2”-“10” instead of alphabetically, which would be “1”-“10”-“2”? No problem! Simply specify sobNumericIntText as the sort criterion. You can also specify the locale identifier and a couple of flags that are applied when parsing the texts. Of course all this also applies to sorting listview groups.
Additionally I improved the ItemGetDisplayInfo event a bit.
I’ve released the next bunch of updates. As yesterday these are bug fix releases, no feature releases.
I have migrated ExplorerListView and ExplorerTreeView to Visual C++ 2010 and fixed some bugs.
I guess some of you did not expect it anymore, but I’ve released a first release candidate of the ShellBrowserControls library.
The library contains two controls: ShellTreeView and ShellListView. ShellTreeView can be attached to ExplorerTreeView 2.0.0 or newer, ShellListView can be attached to ExplorerListView 1.0.0 RC1 or newer. The setup contains only 1 sample, but it demonstrates how to use ShellBrowserControls, ExplorerListView, ExplorerTreeView, StatusBar, TrackBar and Animation to build a Explorer-like shell browser. The sample does not contain much code, but supports things like dynamically scalable thumbnails (in Vista design!), Tiles view, elevation overlays, drag’n’drop, context menus and much more. It also demonstrates how to mix shell items with user-defined items.
ShellBrowserControls has been designed to hide as much of the ugly shell stuff as possible while letting you customize every detail. If you don’t want to bother with shell programming, you will be happy with this library. If you are a control freak and want to control every part of the shell-browsing, you will be happy with this library as well. The only major feature that is missing is grouping support, i. e. currently there is no group view mode (although ExplorerListView supports it).
ShellBrowserControls makes extensive use of multi-threading. Loading of items, icons, thumbnails, details and columns has been moved to background threads as much as possible, so that the GUI remains responsive even if some loading process takes a long time.
If you have questions about the usage of the library, please use the forum. Some concepts seem to be complicated, but my beta tester already assured, that they are very powerful once you have understood them.
When using the controls, do not forget that tree view features are controlled by ExplorerTreeView, list view features are controlled by ExplorerListView and shell features are controlled by ShellTreeView/ShellListView.
This is the most complex software I have ever written. I did extensive tests, but be aware of bugs.
I’ve also released version 1.15.1 of ExplorerTreeView which fixes two bugs.
I’ve released the final of ExplorerTreeView 2.0.0. It fixes a few bugs and is the minimum version that can be used with the ShellBrowserControls.
ExplorerTreeView 1.x isn’t dead yet, just a bit rusty. 🙂 I’ve released version 1.15.0 which has some performance improvements and – more important – runs much more stable. Many thanks to Christian Lütgens for helping me nailing down the AutoUpdate crashes by providing helpful crashdumps and bug reports.
Speaking of crashdumps, ExplorerTreeView 1.x comes with (stripped) debug symbols now.
I’ve released a second release candidate of ExplorerTreeView 2.0.0. I made some compatibility breaking changes to improve performance and to avoid incompatibilities with other controls of mine. You should read the changelog to see what has changed in detail and how your code needs to be changed. I think most of you will get away with a simple recompile.
Now to the better part of this release 😉 You can now specify whether you want Aero drag images or classic style drag images. I’ve also implemented two new events that are raised if the sort order is changed. And of course I’ve fixed bugs.
Under the hood, I’ve worked hard on the interface for the yet-to-be-released shell browser controls. I consider it to be complete.