From CLX to VCL

Back in 2002, when the project was being designed, it was meant to be cross-platform (well, at least Windows and Linux on i386). The choice was Delphi/Kylix; instead of VCL, we used CLX from day one. This was bad - because Kylix is dead by now - but also good, because we were forced to code in a cleaner way - no Windows API calls, very few third-party components, etc.

Coding for both Delphi and Kylix was an {$IFDEF} nightmare. Most coding was being done in Delphi, under Windows, and everytime we fired up Kylix to compile a Linux version, a lot of changes were needed. Then, early this year, some customers started to try the win32 program under Wine, getting very good results. With little effort we made it work 100% under Wine, and it became clear that it was easier to run the application under Wine than code for Kylix.

The CLX is very buggy (and slow); a couple months ago we started to port to VCL. We also evaluated the possibility of porting directly from CLX to Lazarus, but our studies have shown it would be a huge step. So we decided to port to VCL first. A tool was used for this task: Convert Files, by Dennys dos Santos Sobrinho. As expected, the conversion did not worked in the first try; a lot of changes were needed and we could not afford to mantain a branch just for this task. So we decided to gradually reduce the gap, by removing obstacles at each official release.

It was a major refactoring task - a lot of code was rewritten, third-party components were replaced with standard ones (new code was needed to accomplish the missing features), points of conflict of method signatures between CLX and VCL were concentrated in fewer places, xpm icons were replaced by bmp, png or ico files, etc. Every week we tried the conversion process with the current codebase; the gap was becoming small.

And today, at last, we managed to get a working VCL port! It's a lot faster (at least 3 x), a lot of CLX bugs are gone (mouse scroll works now, form focus is not crazy anymore, etc) and with XP Manifest the project got a nicer look under Windows. Of course the entire project needs some revision to fix minor visual glitches, but overall it's working. We plan to issue an official VCL release in a couple weeks.

Installing Lazarus on [K] Ubuntu 5.10

1. Download the Free Pascal Compiler:
http://www.freepascal.org/down/i386/linux.html
http://www.freepascal.org/down/source/sources.html

2. Execute install script for FPC (use all defaults, installs to /usr/local)

3. Untar (tar -xvzf) the sources into /usr/local/src

4. Install (with "sudo apt-get install"):
build-essential
subversion
libglib1.2-dev
libgnome-dev
libgdk-pixbuf-dev

5. Get Lazarus with Subversion (SVN)
svn co http://svn.freepascal.org/svn/lazarus/trunk lazarus
(from now on, change to lazarus directory and run "svn update")

6. Build (use only "make" to build with GTK1 widgetset)
make LCL_PLATFORM=gtk2

That's it. YMMV, of course.

Indy or Synapse?

After trying Indy 4 Lazarus without success, I was told (thanks again, jesusrmx) to try Synapse's HTTP functions (from the HttpSend unit). I've been using Synapse for serial communication, but I was not aware of its HTTP features. I was gladly surprised: it's almost as easy as TIdHTTP and is officially supported on Lazarus.

Now I'll finally port the "Auto Updater" from my project. The preliminary tests were excellent, and as soon as I finish it, there will be another post here.

More on Auto Update

The Auto Update feature uses Indy's TIdHTTP. There's an effort to port Indy for Lazarus, but the Sourceforge file is a bit outdated (almost two years old). So I started to search for alternatives, just in case. I've found LNet (LightWeight Networking Library), written by Ales Katona. In the next days I'll try them all and decide which one the project will use.

Update: after some chatting on #lazarus-ide, I managed to download a newer version of indy4lazarus. I'll test it soon and post here the results.

Auto update

The RNGE system has an auto update feature. An application launcher checks the Version Info data from each EXE against the configurations files on the server; if the versions are different, the launcher downloads the version from the server and overwrites the version on the client.

However this depends on Windows API in order to get the Version Info from the binaries, therefore a crossplatform solution is needed. Joran and fpcfan from #lazarus-ide channel (at Freenode) gave me the idea of using a POSIX compliant command-line argument: --version.

OnPrepareCanvas

The 200 kloc project I'm porting uses only a few third-party CLX components on Delphi 7. The most used by far are TAdvStringGrid (Advanced String Grid) and Synapse (serial communication). The latter is already ported to Lazarus, so I focused on the standard TStringGrid from LCL.

In my code, the event OnGetCellColor (from TAdvStringGrid) is used to change the look of the Cell depending on some conditions. The AlternateColor property solved part of my problems, but I needed to check the Cell's content before it's drawn. Then, after a few searches, I've found OnPrepareCanvas. A simple code to put negative numbers in red looks like this:

procedure TForm1.StringGrid1PrepareCanvas(sender: TObject;
Col, Row: Integer; aState: TGridDrawState);
begin
if not (gdfixed in aState) then
 if Pos('-',StringGrid1.Cells[Col,Row]) = 0 then begin
   StringGrid1.Canvas.Font.Color := clBlue;
 end else begin
   StringGrid1.Canvas.Font.Color := clRed;
 end;
end;

The standard TStringGrid from LCL has all I need: the project is one step closer to be ported. Thanks Jesus Reyes Aguilar for the great work!

Lazarus 0.9.10

It was released at October, 3. I'll make a post at every release.
http://sourceforge.net/project/showfiles.php?group_id=89339

The latest snapshot is here:
http://www.de.freepascal.org/lazarus/

The current snapshot (as of December, 9) is Lazarus-0.9.11-20051209. The warning in the web page is scary: "These snapshots are generated automatically and are untested. The only thing we can say is, that the compiler found the source good enough to compile. These snapshots are provided as a courtesy only. If they don't work, too bad! If they destroy your project files, crash your machine, and eat your disk: Tough luck! (just to say that YOU ARE USING COMPLETELY UNTESTED SOFTWARE)".

Day 1 - First issues

- DB Express has a TStringList named Params; all databases use it, so to access PostgreSQL (the DB I use) there were a line DriverName := 'PostgreSQL'. Using SqlDB, I used the TPQConnection component, and the parameters are now properties.

- My OPF has an option to trim the strings it gets from (or write to) the DB. It used Trim(X) where X is a Variant. FPC did not like that, and I had to change it to Trim(VarToStr(X)). There's hundreds of files that use that construct in my project, but thanks God it's all code that is automagically generated by a custom made tool.

- Bug 4323: the workaround was use ShortDateFormat and others instead of the thread safe TFormatSettings.

- Transactions: Instead of TTransactionDesc, there is TSQLTransaction. It led to a lot of changes, including this one that I'm afraid is not a good one (the condition seems to be different):

if Transaction.Active {FdscTrans.InTransaction} then ...

My OPF controls the transactions, throwing its own errors when you try to start a transaction when there's one started, or try to commit when there's no transaction. Is the TSQLTransaction is always active when the connection is open?

- A weird thing was an error using the LIMIT clause of some SQL queries. I removed them by now, but these LIMIT clauses are needed for the correct operation of the OPF. I will get back to this later.

That's it. Also, there was a lot of strange behaviours of the IDE (remember I'm using Windows XP), but nothing that can be considered a showstopper. It includes wrong syntax highlight, some weird things with Ctrl-Space and ghost carets. Are these known bugs?

The beginning

I started yesterday the porting of a medium-sized application (~200 kloc) from D7 with CLX to Lazarus (using the 2005-12-05 snapshot). I was wondering if a diary of this could be useful - I do not want to forget what I'm doing. Right now I'm porting the custom-made Object Persistence Framework (OPF), and managed to get a working test program already (on Windows XP).