Much later than planned I have released an update of ExplorerListView. The changelog is as long as a novel. Most changes are new features available on Windows Vista. No less important is the implementation of the interface for the upcoming ShellBrowser control. I’ve also fixed many bugs.
Support for Windows 98, ME and NT4 has been dropped because my compiler doesn’t support those systems anymore. But Windows 7 is already supported.
Comments
5 responses to “ExplorerListView 1.0.0 Beta 5”
I am working on a project that has a multilingual user-interface (my own design and development) As I do not speak all the languages I want to add, I get the texts translated by friends and others.
For this I am developing a tool that hides the technicalities from the translators, checks their input and helps them to send the updated texts from within the program.
I had great problems with the Roumanian and Slovakian texts, which I solved first with the MS-office dll, but it was not perfect either, I had to catch and translate a few characters.
But then I found your solution, and am happy to say, that it works even with those, that MS did did not display correctly.
The texts are held and used from an array, but are displayed for selection in a listview. As the MS version is ASCII only, I translate the special characters, which is not the best solution, as it involves new code, when a new language is added.
Therefore I tried your Listview, but found a great problem with it:
You cannot specify ColumnHeaders! (At least I did not find a way.)In my program I create the column for the item and generate the others on the run according to which languages should be displayed.
But as it is still in the beta stage, I assume, that these features will e implemented soon.
But I would like to make a general comment about your controls:
There are so many options, that they do not fit onto the screen, thus making their use a bit difficult.
Couls you consider to move the special-ones to property-pages?
Also your help is more C als VB oriented.
Most VB-users are not interested in Namespaces, Classes, etc, but would like to know the syntax, properties and methods.
I see, that the documentation is not directly written by you, but generated from the code.
But from the Listview documentation I cannot see, how do I add items to the listview, how do I generate new columns, etc.
I have written myself a listview control a few years ago, but for win98, which used some useful features only accessable through APIs.
One of its features was including check-boxes (two images for display and a variable to test) in listsubitems and allowing specific bachground-colours for subitems. (eg as error-marker.)
Greetings from Bavaria
Stephan de Rakovszky
Column headers are specified at runtime. Sub-item specific background colors can be done using the CustomDraw event. Check the samples.
Sub-item state images could be emulated using sub-item images.
Property pages vastly increase the size of the ocx file which already is very large. Therefore I put very few things on property pages.
Concerning the documentation: I auto-generate it from the code because it saves me a lot of time. I use Doxygen for this task and have not yet found a way to make its output more VB6-like. It’s right that you won’t find questions like “How to add columns?” directly answered in there. But there’re sample projects which demonstrate how to do it.
Thanks for your answer.
I must admit, that I did not look at the sample programs at first. The part of the project, where I could use it, is just a small part of a much larger project, which is actually sidetracking me from my own web-site and researches.
But plese do not be offended by what follows, it comes from long EDP experiaence:
1.) the name of this control: ExplorerListview is dangerous and misleading.
a.) you could be forced to change it, although the lawyer specializing in “Explorer Abmahnungen” is in jail now.
b. one thinks, that it has something to do with the Explorer, so it is nothing for him.
I would suggest “Unicode Listview” which would be a more expressive and attractive name, od “ExtendedListview” as your control offers much more than the MS control, or “TimoListview” indicatind, that you have developed it. (I prefix my products with “Rako”).
2.) the samples:
it is very difficult to getfrom them the gist of what the user has to do.
The forms contain all the declares and the routines, that I assume are normally in the OCX.
I have a DLL with the references/interfaces, which I use during the development, but which do not have to be released to the user. (But could be needed with the samples.)
I have a module with all the declarations. Clean, no logic, but with all both the A and W declarations I might need for the entire project.
To this module I have an API-interface module with just call for the A/W APIs. Right at the beginnin I test whether the A or W APIs are needed, and in the wrapper-function I call the appropriate one, making any necessary changes.
This approach avoids the need for separate ASCI and Unicode modues.
The main functions of the control are also in a separate module, They call the wrapper API-functions. I went even further, separate SendMsgLongs for Listview/Treeview, etc functions, as in many cases just one parameter is required, so why complicate the logic parts with the standard (zero) values. The overhaeads of this approach are minimal and save a lot of time and effort.
As you issue your controls free like free beer, if you want I can let you have these declare and API-interface modules for the use in your controls.
1 b) The name is not as misleading as one might think. Combined with a yet-to-be-released control ExplorerListView may be used for shell browsing just like Windows Explorer. When I started to program ExplorerListView, I planned to implement these features directly into the control. The decision to make a separate control was made later and the control’s name remained. Today I would choose the name ListView, but changing it now would totally break compatibility.
2. I’m not sure what you mean by “The forms contain all the declares and the routines, that I assume are normally in the OCX.” Do you expect those declares and routines to be implemented directly into ExplorerListView? Which declares and routines exactly?
Concerning the A/W stuff: Pre-processor directives are resolved on compile time and don’t cost any performance. Wrapper functions *do* cost performance. But since my controls don’t work on Windows 98/ME anymore, the ANSI stuff has become somewhat pointless. Maybe I’ll remove the A/W hell and always use Unicode API calls instead.
1.) I do not think, that changing the name now would cause compatibility problems. As it is still in the beta phase, you could change it before you may be forced to do it.
2.) In the samples all declares are coded into the forms.
3.) you cannot avoid wrapper functions, because in some cases you may have to convert things from unicode to ansi or vice versa. It is just VB that is funny. In a wrapper function you an catch these without affecting the caller routines.
Wrapper-functions may incease safety by having their own parameters which are converted to the actual ones there. (compatibility problems)