Our component got recently reviewed by Mike Riley. The review has a very positive tone. Here are some excerpts:
From the Better ListView review at DevProConnections.com:
In addition to creating a new ListView control to incorporate broader flexibility and functionality, Better ListView could also be called Fixed ListView, as it corrects a number of annoying problems with the standard ListView that Microsoft delivers to Visual Studio customers. For example, drag and drop and check boxes actually work they way one expects, and column headers and list sorting behave the way they do in the Windows Explorer and other native Windows OS applications. Likewise, improvements that go beyond the standard ListView, such as support for various image sizes and locations (in the column header or subitems, for example) further elevate Better ListView beyond Microsoft’s offering.
The review also states:
The control is very easy and intuitive to use and is well documented
The reviewer found the product obviously immensely helpful:
The enhancements I found most useful for my own projects were the automatic layout, context menus, improved drag and drop, item searching, and sorting options. Thanks to both the source code–included demos, the online documentation, and the obvious property names of the control’s “better” features, I was able to put the component to use faster than it took me to install the setup package.
The only negative thing mentioned in the review was our pricing:
Although I found using the control fast and intuitive, the one aspect that is a downer is the price. Considering that this is the era of .NET component bundles that offer hundreds of components, pricing this single .NET Windows Form control at the price ComponentOwl has is too high for my tastes.
Let me elaborate on that a bit. Although there are huge component packs for .NET, not a single one of them has a list view like our Better ListView. Most of the list view controls included in “packs” are simply not as powerful, which is only logical. Developers of these packs simply can’t focus their development just on the list view control that much, as they also have other 100 controls to develop and update.
However, the biggest drawback of list views that are part of a component packages is this: They usually implement their own class names and conventions, but what’s worse, their own custom look and behavior. These list view controls usually do not look and behave like native list view should. They can easily frustrate the user, right during the first few seconds of using them. I think that the first impression is important. So these controls are not easy drop-in replacements, but rather a whole different approach, which may be suited for some projects, but is IMHO inferior for standard Windows desktop applications, as compared to using controls that respect native look and behavior, like our Better ListView does.
Yes, we are perfectionists.