[Lazarus] Note: Local variable "$defaultbufpos" not used

[Bernd]

> Not that i think this is a big issue but, AFAIK, mixing licenses are 
> not so straightforward even if is toward a more liberal.
OK. We can always ask Mike about this. I am sure he wouldn't object to 
adding LPGL.
>> I am glad that you're working on VT, but wouldn't it be better if you 
>> started off with v5.x instead of v4.8.6?
> Maybe you dont know but i started more than 3 years ago: 
> http://lazarusroad.blogspot.com/2007/02/ports-of-delphi-components.html
I have been away from Delphi for about 4 years. Hence, I didn't know.
> Aside that point, i already split the svn to prepare to merge the 5x 
> changes. I just did not yet (and it's easy) because there are API 
> breaking changes in 5x and this will break some code out there, 
> including mine. Also the code is not wild tested so can be some bugs. 
> This can lead to some confusion: the bug is from the LCL port or from 
> 5x version changes?
>
> The idea is: fix the remaining issues with 4.8.6 and wait for a 5x 
> version be released in Delphi side so the merge can be more safe.
API changes, radical ones at that, are bound to happen --especially if 
TObject-ifying is on the cards.

Maybe a better idea is to have 2 different branches; one for v4.x and 
another one for v5.x --and rename the v5.x component something else so 
that both can be present simultaneously (which is what I did, for my own 
internal use at the time).
>> Refactoring it as 'TVirtualNode = class(TPersistent)' solves many of 
>> those problems (not least of which is the issues with TWorkerThread 
>> which becomes totally redundant) and paves the way for future expansion.
> Agree. Just two points:
>
> - The  main philosophy behind the port is to keep the original code 
> where possible. So the node handling/logic is almost identical from 
> Delphi, i just changed parts related to painting that was impossible 
> to implement as in the original, like the header (that uses non client 
> area) or the painting of checkboxes (that was not working cross 
> platform).
>
> -This is a feature to be implemented in version 5x:  
> http://code.google.com/p/virtual-treeview/issues/detail?id=3 . The LCL 
> port will take advantage as soon is implemented (and released) there.
I have code lying around here from 2007 (v4.3.1) when I refactored VT to 
use  TVirtualNode = class(TPersistent); and everything else was also 
modified to be class/object based (as opposed to pointers/records). I 
also converted the Advanced Demo to run with it.

The only thing that needed to be done was to further refactor the code 
so that each TVirtualNode handles its own painting --rather than having 
the main tree do it, as it is currently done in the calssical VT. That 
would make deriving new node classes much more easy.

But, as you must have guessed, objectifying VT is a radical departure 
from the classical VT in that code using it will need re-examining.

Can't promise, but I might check what new bug-fixes there have been so 
far, and incorporate them in my version.

Of course, you, or anyone else is/are welcome to take a look --just drop 
me a line and I'll send a copy.

Cheers,

Adem