QvasiModo,
can u show me the code for changing an item's default blue surrounding rectangle color? (not item's text color/bk)
u have too many inc files :D
i want to implement that in a listview control.

btw,
you app crashes when setting the 4th algorithm on WinXP SP1
thnx
Posted on 2003-08-30 17:15:49 by wizzra
In TreeProc.inc you have all code related to handling the treeview window procedure. There you will find in the TreeProc procedure, the code to process WM_NOTIFY messages. I't's the items owner drawn messages that you have to handle. Listviews work exactly the same way, but the constant and structure names are slightly different, you will find all the differences in MSDN.

Remember that in this particular project, WM_NOTIFY in handled in the treeview procedure because I made the the dialog proc forwards those messages. In a normal situation you would handle them in the parent window's procedures instead (no need to subclass).
Posted on 2003-09-01 09:46:46 by QvasiModo

btw,
you app crashes when setting the 4th algorithm on WinXP SP1
thnx

I was unable to reproduce the bug... could you please give more info? (exactly how and when this happens, etc.). It would also be nice if you load the program with a debugger and tell me where in the code is the GPF. :)
Posted on 2003-09-04 12:46:37 by QvasiModo
after reboot the app didn't crashed anymore..
Posted on 2003-09-04 14:13:17 by wizzra
Vain attempt at converting this into a RadAsm custom control... it GPFs right after WM_CREATE is processed.
Any help? :(
Posted on 2003-09-04 14:24:58 by QvasiModo

Hi, I'm back from a nearly one week episode of flu (not completely over yet :grin: ).
I'm posting here my (probably last) version of the treeview thing. I got bored, really. If someone comes up with the solution to the double click problem I'll update, but I don't feel like working on it anymore. :(
As for the listview problems, how is it going? Are you implementing the FAT idea? We could do it here in the board, since code for a custom heap could be reusable, it would help a lot of people (and sure would be fun to code it :) ).


You're back, or were SOOO long ago, so am I, on and off. I've been overbusy, plus had a slight difficulty in connecting (operation on shoulder, prevented me from being at keyboard a lot). And I got into programming other projects further. Finished one (not the one I wanna finish), but one that needed to be, another is on the go (an ack, anti spam filter). I do want to get to that FAT (or RAT since it's ram really), actually prototyped the structures, figured out how they're used, what functions are needed to add/delete/cleanup the table, etc.

Just to get time to start writing the code.

Sorry to hear you're giving up on that treeview. (I guess you have to try something new too.)

Wow, it's been months. :( Atleast now I can be back at a regular interval.
Posted on 2003-11-16 09:01:07 by FunkyMeister
Long time no see... :)




You're back, or were SOOO long ago, so am I, on and off. I've been overbusy, plus had a slight difficulty in connecting (operation on shoulder, prevented me from being at keyboard a lot).

Sorry to hear that... :( Hope you get well soon.

And I got into programming other projects further. Finished one (not the one I wanna finish), but one that needed to be, another is on the go (an ack, anti spam filter). I do want to get to that FAT (or RAT since it's ram really), actually prototyped the structures, figured out how they're used, what functions are needed to add/delete/cleanup the table, etc.

Just to get time to start writing the code.

Sure, it's a great idea to have a high performance virtual list view. Post the structures, I'm really interested! :alright:

Sorry to hear you're giving up on that treeview. (I guess you have to try something new too.)

Well, that treeview thing was pretty much of a dead end, since each version of the common controls had so many little differences, and one had to handle them all. Coding a fully custom draw treeview was much safer, and maybe not so much more trouble... ;)

Wow, it's been months. :( Atleast now I can be back at a regular interval.

Hey, welcome back. We've been missing you. :)
Posted on 2003-11-17 11:27:22 by QvasiModo
I did not read all replies (6 pages :) ) but i wanted to make a mark about the painting process.

I think that you should draw the bitmap during WM_ERASEBKGND.
Use GetClipBox() api to determine invalid range and draw that part onto the DC.

Let Windows paint the items itself..
Posted on 2003-11-17 11:37:18 by Edwin Knoppert
Don't worry, I don't remember all replies (6 pages :grin: )
Anyway I vaguely remember that wasn't working because the treeview control was overwriting anything you did during WM_ERASEBKGND. But it's worth trying anyway. :)
Posted on 2003-11-17 11:39:48 by QvasiModo

Long time no see... :)

Sorry to hear that... :( Hope you get well soon.


Only time will tell on that I'm afraid. But, I'm optimistic that I can atleast keep computing, other stuff will be with pain, but, life is pain so I just keep living. :)


Sure, it's a great idea to have a high performance virtual list view. Post the structures, I'm really interested! :alright:


Here it is: (No committing suicide over it, please!)

Memory RAT:


Control Block:

Comment: Block used to record memory usage of Data & Data Control blocks
Size: 1024k Static
Format:

00000000h Pointer to next Control Block.
00000004h Pointer to next Data Control Block.
00000008h Next location of NEW Data Element structure.
0000000Ch to 000FFFFFh contains Data Element structures.

Data Control Block:

Comment: Block used to keep track of memory allocs. 2,147,483,647 max per chunk.
Size: 64k Static
Format:

0000h Next location of NEW Data Usage structure.
0004h to FFFFh Contains Data Usage structures.


Data Usage Structure

0000h Alloc Address of the allocated chunk
0004h Pointer Address to the next available large chunk
0008h Size Size of the available chunk

Data Element Structure

0000h Pointer Pointer to the chunk (within a Data block)
0004h Size Size of chunk.
0008h Flags Flags consisting of only 1 bit (31 reserved, else available).

Bit 31 used to denote if the data chunk is used (1 if used, 0 if not).


Notes:

Using 1 meg alloc sizes for Data Blocks, with one Data Control block, you can handle 22,905,094,144 bytes in Data Blocks.
The large Control Block size allows for 87380 entries before a new block is needed.
Data Control Blocks will rarely need to be added due to their size and how much information they can control.


Routines needed:

Internal:

Cleanup Scan Control Blocks and merge data chunks if possible, moving all "unallocated" memory chunks to the end of the LAST Control Block.
(ICB)
cAlloc Alloc a new Control Block and link to previous (if ICB is not null).
(ICB)
bAlloc Alloc Data Control Block for the last Control Block (or first if no next). Always do this, no return code if this finds no unalloced Control Blocks.
(CB)
dAlloc Alloc Data Block for the next Data Control Block's Data Usage (or first if no next). This will get called if the first Data Control Block has no Data Block or the element prior has no free space for the new element.
(CB)
mAlloc Scan Control Blocks for available Data Block space for requested size, doing the following:
Check ICB for a Data Control Block, if not, call bAlloc(CB)
Check LAST Data Control Blocks for a Data Block, if not, call dAlloc(CB)
Check LAST Data Control Block's Data Block for space, if not, call dAlloc(CB) for a new one.
Repeat
Check Control Block for space on where to put Length, if no space available, call cAlloc(ICB).
Repeat
(ICB, Length)
Calls AddEntry to retrieve the pointer of the newly created Data Element structure to return.
AddEntry Calls Cleanup to clean up the Control Blocks before attempting to find a new Data Element location.
Returns the LAST Control Block's pointer to the next Data Element (OR creates a new Data Control Block if no space exists for one).
(CB, Pointer, Length)
Find Finds the Item # throughout the Control Blocks.
(ICB, Item #)
Returns a pointer to the Data Element or null if it didn't find it.
DelEntry Takes the current item, adds it to the end of the LAST Data Control Block, then moves ALL entries up one position, cross Data Control Block moving, until the last item is reached (which is "unallocated" before it's moved).
(ICB, Item #)
Returns TRUE if it found it, NULL if it didn't.
InsEntry Checks LAST Data Control Block for entry space, if not, call cAlloc.
Checks LAST Data Control Block for entry space, if not, fail. (Memory constraints)
Rolls last item of full Control Block onto the next one (and repeats) until the entire list is rolled up one item #.
(ICB, Item #, Length)
Returns either the pointer to the Data Element structure or null if it couldn't insert (Memory constraints)

External:

Init Setup the Initial Control Block ONLY, the allocs of new Data Control blocks is done when an item is added. As is the Data block. The first element added will be the slowest.
(AllocSize) AllocSize should be 1 meg or higher, it'll cut down on massive allocs. If null, defaults to 1 meg.
Returns pointer to Initial Control Block (used when you communicate with it, called ICB).
Add Add element (this is a 1D array). The user can break the data up using nulls, since the Add requires a length.
(ICB, Pointer, Length)
Returns TRUE if it worked or FALSE if it failed (fails usually only with memory or length at 0).
Edit Edit the element that is selected, the current element can be smaller or larger, when larger, the original memory chunk is "freed" and new memory is "allocated" for that slot.
(ICB, Item #, Pointer, Length)
Returns TRUE if it worked or FALSE if it failed (fails usually only with memory or length at 0). If a failure happens, the original is untouched.
Get Retrieve the item #, returns either null if it couldn't find it, or a pointer to the Data Element structure of the item.
(ICB, Item #)

GetBits Retrieve the item #'s bits (0 to 30, 31 reserved), this is used instead of retrieving them via the internal structure.
(Item Pointer) <- Must be an Item Pointer, from the Get function (since using the find more than once on an item is stupid).
Returns TRUE if it worked, or FALSE if it didn't work (invalid Item Pointer).

SetBits Set the item #'s bits (0 to 30, 31 reserved). Same as GetBits.
(Item Pointer) <- Must be an Item Pointer, from the Get function (since using the find more than once on an item is stupid).
Returns TRUE if it worked, or FALSE if it didn't work (invalid Item Pointer).

Insert an item at the Item # location.
(ICB, Item #, Pointer, Length) See Add for info.

Delete Delete the item #, returns either null if it failed (couldn't find it) or TRUE if it deleted the item.
(ICB, Item #)

Destroy Destroy the entire set of data (the fast part, it goes through all of the Data Blocks present, removing them, then all the Data Control Blocks and finally all the Control Blocks).
(ICB)
Returns TRUE if it found the ICB and destroyed it, or FALSE if it didn't.

----

Just some light reading. :D (I've attached the RATproto.txt file, since this seems to eat the formatting. Feel free to mull it over and see if there's any better way to do this.)

Above is the RAT Prototyping I did, basically it's how the memory storage/retrieval system works. Well, in theory anyways. :) I've not actually delved into that brain intensive work yet.


Well, that treeview thing was pretty much of a dead end, since each version of the common controls had so many little differences, and one had to handle them all. Coding a fully custom draw treeview was much safer, and maybe not so much more trouble... ;)


Does that mean you're going to make a custom treeview? (Possibly work RAT into it?) I know, RAT. FAT for files, RAT for ram. (MAT just sounded, silly, RAT sounds nasty, nasty is better than silly. Well, in most cases.)


Hey, welcome back. We've been missing you. :)


I've been missing this place because of the work I still have yet to do. I want to get winsock patching done still, so I can check for calls going in and out, but I also need to interject urls, so I can tell what url is being asked for. Thats the hard one.

FM.
Posted on 2003-11-17 15:24:39 by FunkyMeister
O, ok..

I can imagne, for listview and treeview is so differently handled by the common controls.
The ownerdraw part should be used instead i guess.

I ever wrote a treeview similar as the OutLook Express message counter (the colored number near the newsgroup entry).

But it seems it works ok at this time?
Posted on 2003-11-18 05:05:58 by Edwin Knoppert

O, ok..

I can imagne, for listview and treeview is so differently handled by the common controls.
The ownerdraw part should be used instead i guess.

I ever wrote a treeview similar as the OutLook Express message counter (the colored number near the newsgroup entry).

But it seems it works ok at this time?


Without doing the ownerdrawn part, it's only capable of handling 32767 entries (sanely), when I have files that have over 150,000 entries. Somewhat won't work with anything else.

So a method of recording mass data storage fast, is necessary to ensure how fast it works.
Posted on 2003-11-19 17:40:09 by FunkyMeister
Updated version. Some silly changes and fixes.
The big change is that it's now located in it's own DLL file, so it should be easier to include it in your apps without having to mess with the sources.
Posted on 2003-12-26 11:27:59 by QvasiModo