How to install VirtualTreeView to lazarus on Linux?

[Человек_Борща]

Greetings!

I've installed beta Lazarus 1.3 jn Ubuntu 14.04.

1. Compile LCLExtensions from LUIPack. Done.
2. Compile VirtualTreeView package. FAIL:

Code: [Select]

VirtualTrees.pas(9305,3) Error: Identifier not found "ZeroMemory"
I'm using a new port on VirtualTreeView also from SVN.

Doing the same under nomal Lazarus DEB's from reposiory, gots the same errors...

What I'm doing wrong? In Wiki, Lunix compability is declared.

[Cyrax]

Try to compile branch 4.8 instead of trunk.

[Groffy]

Lazarus 1.4RC3 - qt - 32bit/ Linux Mint 17.1 KDE - 32 bit

Hello,

I had the same problem - solved with VirtualTreeView 4.8 branch

Ulrich

[marcov]

The new VTV maintainer seems to have stripped all Lazarus support from the "5" branch.

[Marius2]

He also removed XE support which was kind of a shock to us.
(well the VT svn trunk wasn't compatible with fpc/laz anyway)

[LuizAmérico]

There's some confusion here (not your fault, is really confusing).

Some history:
There was a VTV port by Joerg Thaler,Christian Ulrich hosted at Lazarus-ccr. It used the approach to comment code that were buggy or not implemented in LCL. This lead to a largely incomplete port.
So i started  a new VTV port long years ago at BountySource. I took another path: as soon as i hit a code that was buggy or not implemented in LCL and its widgetsets i reported in Lazarus bug tracker providing patches when doable. In parallel i created a support package implementing API that does not make sense in LCL (LCLExtensions). Sometime later i was asked by a Lazarus dev (Vincent) to move to Lazarus-ccr initially under the virtualtreeview-unstable repository, later renamed to virtualtreeview-new. The original port is still there.

Changes in VTV delphi repository were backported to the Lazarus port and were in more or less in sync by the times of 4.8 release. At this time Mike Liesche stopped working in VTV and development stalled. When work was resumed in 5.x branch, initially i did not backport. Only later i separated 4.8 from trunk in virtualtreeview-new repository and started to sync Delphi VTV 5.x/trunk with virtualtreeview-new/trunk. Since than virtualtreeview-new/trunk has became unstable because of changes in interface or windows specific code introduced while doing the backport.

Currently the virtualtreeview-new/trunk has most of the 5.x code ported but needs some work to get in a decent shape specially for non windows. With the move of VTV to github things will be easier since git has features that allows to maintain forks tracking and merging changes from the original in a structured way. Until now i was doing almost manually (with help of tools like araxis merge, smartsynchronize and meld)

[Groffy]

The new VTV maintainer seems to have stripped all Lazarus support from the "5" branch.

The trunk version is compiling under Win7 /qt without problems. Under Linux (Mint 17.1) procedure ZeroMemory() seems to be not implemented. This procedure contains only

procedure ZeroMemory(Destination:PVOID; Length:DWORD);
begin
  FillChar(Destination^,Length,#0);
end;   

where FillChar() is implemented in assembler. Is that somehow platform specific to implement on x86/x64 systems?


Best regards - Ulrich

[taazz]

The new VTV maintainer seems to have stripped all Lazarus support from the "5" branch.

The trunk version is compiling under Win7 /qt without problems. Under Linux (Mint 17.1) procedure ZeroMemory() seems to be not implemented. This procedure contains only

procedure ZeroMemory(Destination:PVOID; Length:DWORD);
begin
  FillChar(Destination^,Length,#0);
end;   

where FillChar() is implemeted in assembler. Is that somehow platform specific to implement on x86/x64 systems?


Best regards - Ulrich

fillchar fills the variable space destination^ with length count of 0s.
In short it is implemented correctly. fillchar is part of the rtl in fpc used heavily in various scenarios  so there is no way that there is a problem on this procedure.

[Groffy]

fillchar fills the variable space destination^ with length count of 0s.
In short it is implemented correctly. fillchar is part of the rtl in fpc used heavily in various scenarios  so there is no way that there is a problem on this procedure.

So for the procedure ZeroMemory() its just a missing declaration in the Linux depending rtl part? In fact, I couldn't find this procedure anywhere else in the rtl.


Ulrich

[marcov]

So for the procedure ZeroMemory() its just a missing declaration in the Linux depending rtl part? In fact, I couldn't find this procedure anywhere else in the rtl.

No, it is a portability bug in the original source. It should simply use fillchar.   zeromemory is a windows API helper macro, and a lot of old API examples used it, which is how it came into the collective Delphi memory.

People simply translated such examples it 1:1 and because on Windows it doesn't matter, nobody thought twice about it. But it is a porting hazard, and should be cleaned up.

Just remove the unit Windows from the uses clause, and it'll probably stop working on Windows too.

[taazz]

I'm going to install it later tonight and see for my self what are the problems in linux. I assume you are installing the virtualtreeview-new and not the unstable trunk but a more stable release.

[Groffy]

No, it is a portability bug in the original source. It should simply use fillchar. zeromemory is a windows API helper macro, and a lot of old API examples used it, which is how it came into the collective Delphi memory.

@Marcov, thank you for your explanation. I have to confess, that when I came over from delphi, I did not dig into that platform independ abstraction layers.


Ulrich

[Groffy]

I'm going to install it later tonight and see for my self what are the problems in linux. I assume you are installing the virtualtreeview-new and not the unstable trunk but a more stable release.

@taazz : As long as I was on Windows / qt, I was fine with lazarus-ccr/svn/components/virtualtreeview-new/trunk. For my Lazarus 1.4RC3 installation on Linux Mint - KDE, I moved to lazarus-ccr/svn/components/virtualtreeview-new/branches/4.8 which compiles for me.

Ulrich

[LuizAmérico]

I removed zeromemory

But even if it compiles probably will not work correctly, since the v5/trunk port is not done yet

Please use branch/4.8

[Groffy]

I removed zeromemory

But even if it compiles probably will not work correctly, since the v5/trunk port is not done yet

Please use branch/4.8

Trunk now compiles under Linux 32bit - thank you!

Ulrich