Thursday, February 15, 2007

Traps of Delphi to Lazarus conversion

There's only a thing worse than a bug difficult to resolve: a bug difficult to find. As an example, i was getting a weird bug in the drawing of VTV. The colors were being painted wrongly and only after a few hours i figured what was going on. See the code below:

with Canvas do
begin
[..]
Brush.Color:=Color;
[..]
end;


Apparently nothing wrong. But the Devil resides in the details. Under Delphi there's no TCanvas.Color while there's in LCL. The result of this code, in Delphi, is that Brush.Color is assigned to TControl.Color. In LCL, Brush.Color is assigned to TCanvas.Color (which in your turn points back to Brush.Color!!).

You can't even say that there's a bug in LCL or in the program. Is just one of traps found while converting Delphi code.

The same occurs with TCanvas.Width/Height (does not exist in Delphi) and TBitmap.Width/Height when used inside compound "with" statements.

Monday, February 12, 2007

Children of the port

A working new VirtualTreeview is far from reality but there are already some results.

Since this is really a complex software, a lot of debugging will be necessary so i needed to extend the Multilog component/package. I just released a new version. But one of the functions i added was the ability to log memory areas and i needed a component to display it. This way i ended porting ATBinHex (in fact is a grandchild of the port ;-)).

As a bonus i implemented TOleStream that was missing from Delphi.

You can find them at https://luipack.bountysource.com/

Saturday, February 03, 2007

Ports of Delphi components

Last week i started to port two Delphi components: the already know VirtualTreeView and ATBinHex a Hex viewer. At the moment VirtualTreeView is compilable but does not work and ATBinHex works under Windows only. Both code can be get in LuiPack, a project i started to centralize and help keep track the components i develop.

Before someone would ask: "Why do a new port of VirtualTreeView if already exists one?", here are the answers:

  • The original port of VirtualTreeView (VTV) was based in version 4.0.17 from December 2003. Currently we are in version 4.5.1. A lot of changes happened after that. One option was to see what changed and than backport to the lazarus version. But two problems arise: At the time of 4.0.17 the VTV code was not in a version control system making hard to know what changed. Furthemore, the chances that applying these changes would conflict with the modifications done in lazarus port are high.
    So this time, the VTV code is in a svn server being easy to see what changed and than backport small modifications to lazarus if appropriate.
  • Some features were removed in the port process (CheckBox images, AlphaBlending, Bidi support) and other bugs introduced. To completelly fix them and add the missing features would require deep knowledge of how VTV works and the success was not guaranteed. So i believe the work to do a new port would be only a more hard than to fix it.
  • In that time LCL/fpc was far from what is now. This allow to do a easier port without the need to remove features. So, instead of removing features the idea is to fix the LCL, where appropriate or redo with LCL/fpc functions.
PS: Don't expect a working VTV soon, because of the decision to not remove features will lead to a long road.