ExplorerListView 1.0 development diary

Post by **TiKu** » 23 Mar 2005, 18:41

Like I did when developing ExplorerTreeView 2.0, I'll inform you about the process of developing ExplorerListView 1.0 in this thread.

What's done?
- basic listview features like FullRowSelect, HotTracking, InsertMarkColor, MultiSelect, View...
- an IMEMode property as known from Microsoft .net
- properties concerning the label-edit field (BackColor, ForeColor, Text, IMEMode, HoverTime)
- column management
- item management
- sub-item management
- group management
- working area management
- CustomDraw
- ToolTips
- background image support
- dozens of events covering all features that are implemented so far
- DisabledEvents (makes time-consuming events deactivatable)
- item sorting
- group sorting
- Drag'n'Drop
- OLE Drag'n'Drop
- virtual mode
- property pages

What needs to be done?
- all shell stuff (at the moment it's just a plain listview control)

What am I currently working on?
Nothing, because I've to learn for exams.

TiKu

Post by **TiKu** » 03 Apr 2005, 01:43

Column management is complete. Next is item management.

Post by **TiKu** » 10 Apr 2005, 00:01

Some of you may wonder why this diary is so empty in contrast to ExplorerTreeView's diary. Well, I make much faster progress than I thought I would do and there're no problems I could write about. So in this case silence is a very good omen.

I can reuse big parts of ExplorerTreeView. Sometimes it's really boring, because I'm just copying and pasting. :buck:
Item management probably will be complete within the next 24 hours. The next step is sub-item management. There shouldn't be much work necessary.

Post by **TiKu** » 19 Apr 2005, 00:53

Sub-items are working and I went on to groups.

Post by **TiKu** » 20 Apr 2005, 23:32

Okay, it was just a question of time when first real difficulties would arise.
Currently I'm implementing item grouping stuff. LVM_MOVEITEMTOGROUP doesn't seem to be implemented in WinXP's SysListView32. From what I found at Google Groups, the same goes for LVM_MOVEGROUP. The way you identify groups, is strange: Some messages use a zero-based index, most use an ID. It seems like this ID can be changed after group creation - don't ask me what this is good for, it just complicates things even more. And last but not least, I've the impression (I didn't really test it so far) that a group can have 2 different IDs: An unique one and another one that isn't required to be unique.
Changing the title of a group work's under some special circumstances only. And so on...

The grouping stuff in SysListView32 is seriously broken and badly designed.

Post by **TiKu** » 21 Apr 2005, 11:21

TiKu wrote:And last but not least, I've the impression (I didn't really test it so far) that a group can have 2 different IDs: An unique one and another one that isn't required to be unique.

I must correct myself. There're no 2 IDs and IDs have to be unique. But you can't update some settings of a group (like title alignment) without changing its ID. :crazy:

Post by **TiKu** » 27 Apr 2005, 20:38

Basic group management is complete, so I can focus on the properties of the ListViewGroup class now.

Post by **TiKu** » 01 May 2005, 00:11

Grouping stuff is complete. Working areas should be easy to implement.

Post by **TiKu** » 07 May 2005, 22:59

Working areas are done. I'm not sure what will be next. Probably all those events, but yesterday I had a look at the ListView control of .net 2.0 and it supports virtual mode. Virtual mode is something I didn't plan to support at all, but if even the standard listview of .net supports it...

For those of you who don't know what I mean with virtual mode: Windows' SysListView32 has a mode where it does maintain a minimum of information and no item-specific information. Instead it asks the application anytime it needs something. This way the listview can contain millions of items without a performance hit.
While this sounds good, many limitations take place in virtual mode. And the COM overhead eats some part of the performance gain. That's why I didn't plan to implement virtual mode, but now I'll rethink my decision.

Post by **TiKu** » 25 May 2005, 15:28

I'm working on custom draw and the events. While custom draw makes some trouble, most events are done.

Post by **TiKu** » 29 May 2005, 15:49

Custom draw is working. I'll upload some screenshots into the album section soon.
Yesterday I implemented the HeaderItemGetDisplayInfo event. It's based on HDN_GETDISPINFO and gets fired if you've set a column's caption to 'Empty' and that column is to be painted. HDN_GETDISPINFO seems to be broken. It should provide the index of the column it was sent for, but often this index is some garbage like 0x13302. I had similiar problems with the listview's custom draw notifications. Such things slow me down very much.

Post by **TiKu** » 01 Jun 2005, 23:05

Tooltips are working. I hope to get item sorting finished tomorrow.

Post by **TiKu** » 02 Jun 2005, 21:58

Item sorting is working and group sorting will be finished this night. Looks like I'll start implementing Drag'n'Drop next week.

Post by **TiKu** » 06 Jun 2005, 00:11

TiKu wrote:Looks like I'll start implementing Drag'n'Drop next week.

Okay, this was too optimistic. :buck: I've made a list with all features of SysListView32 that my control does not yet support. Besides drag'n'drop and virtual mode, there're still some small unimpressive things that need to be done.
I hoped to get Beta 1 out before I've to prepare for exams, but this goal will be difficult to reach.

Post by **TiKu** » 17 Jun 2005, 15:35

I'm more or less ready to start implementing drag'n'drop (which should to 95% be copy & paste from ExplorerTreeView). However, I'm dissatisfied with the current way of filtering items - in ExplorerTreeView as well as in ExplorerListView.
Let's take a look at the TreeViewItems collection of ExplorerTreeView:
It can be filtered by the items' selection state and their state-image index. Fine. But it can't be filtered by the ItemData, Ghosted or HasPlusMinusButton properties. Especially filtering by ItemData would be very handy (I already needed it). Also the current filter settings are of including nature always. You can't tell the control "give me all items except ghosted ones".

Another "problem" is the dirty interface design. Filters affect the TreeViewItems collection, but you set them as parameter of the RootItems, TreeItems and SubItems properties and can't change them later. There should be something like a TreeViewItems::Filters property.

So, I've told my installation of Subversion to create a new branch in my ExplorerTreeView repository. I'll use this branch to try a new filter system. If I get it working the way I've planned it to work, I'll merge it back into the trunk branch and also port it to ExplorerListView; otherwise I'll go on with the current system.
Maybe I can even get rid of the TreeViewItemContainer class which internally isn't easy to handle. This would affect drag'n'drop and that's the reason why I won't implement drag'n'drop in ExplorerListView before I've decided about the filter system.