Porting status

The porting is officially paused.

In the last few months, a number of changes were made to the main project (written in Delphi) in order to help the porting to Lazarus - mostly the replacement of problematic components. These changes, helped by recent versions of Wine, improved immensely the emulation under Linux. Right now the software runs smoothly under Wine for 99% of the user profiles.

StrToDateDef, RoundTo and BoolToStr

Delphi has 2 functions not present in FPC:

function StrToDateDef(const S: string; const Default: TDateTime): TDateTime;
function RoundTo(const AValue: Double; const ADigit: TRoundToRange): Double;

The first one tries to convert String to TDateTime, and if the conversion fails, the result is the value informed at the Default parameter. The second one does banker's rounding to a given precision, informed in power of ten. To round to cents, you need to pass -2, as 10 ^ -2 is 1/100.

There's another function that is present but has different behaviour. It's BoolToStr:

//--- Delphi's BoolToStr
function BoolToStr(B: Boolean; UseBoolStrs: Boolean = False): string;

If UseBoolStrs is false (the default), it returns '-1' for true and
'0' for false. If UseBoolStrs is true, it returns the strings 'TRUE'
and 'FALSE'. In Free Pascal it's like this:

//--- in objpas/sysutils/sysstr.inc
function BoolToStr(B: Boolean): string;
begin
  If B then
    Result:='TRUE'
  else
    Result:='FALSE';
end;

So a call to BoolStr(true) would return '-1' in Delphi and 'TRUE' in FPC. I don't know if it was pointed before, and I agree that returning 'TRUE' makes a lot of sense, but when porting an application this may lead to trouble. A simple "fix" would be add an extra boolean parameter, with the default value of true:

//--- in objpas/sysutils/sysstr.inc
function BoolToStr(B: Boolean; TF: Boolean = true): string;
begin
If TF then
begin
If B then
Result:='TRUE'
else
Result:='FALSE';
end
else
begin
If B then
Result:='-1'
else
Result:='0';
end;
end;

Of course, some may oppose to this change, as it would be a hack made just in order to keep Delphi compatibility.

MDI, qtintf70.dll, launcher... all gone

Several changes has been made in the last few weeks. I also managed to actually convert and open the entire project on Lazarus - as expected, it's not compiling yet. The major changes are:

• No more MDI: all remaining MDI Forms are now converted to SDI;
  
• No more qtintf70.dll dependency: after a complete cleaning, no more QT Units are being used. There were a couple QTypes that were missed in the automated CLX - VCL conversion;
• No more Launcher: the old launcher checks if there's a newer version in a given web server, and using Indy it downloads it; after that it runs the application. Now the own client app does that (using Synapse), calling an external program only if there IS a new version (the external program, already a Lazarus application, only swaps the downloaded file with the file that were being run).

Now I'll focus in the conversion, in order to actually get the project compiled. I know that get it compiled and get it working are two very different things, but hey, I own the damn company. There's no deadline: it's ready when it's ready!

Lazarus 0.9.12

This release is based on FPC 2.0.2 and the binary packages now contain many standard packages: RunTimeTypeInfoControls, Printer4Lazarus, CGILaz, CGILazIDE, MemDSLaz, SDFLaz, TurboPowerIPro, JPEGForLazarus, FPCUnitTestRunner, FPCUnitIDE and ProjTemplates.

Here are the full announcement and the download page. Enjoy!

Converting a MDI form to SDI

In the Form itself:

1. Change FormStyle property to fsNormal;
2. Change Visible property to False;
3. Remove the line "Action := caFree;" from OnClose event;
4. Change property Position to poDesktopCenter or something else (optional);
5. Override CreateParams to add extra funcionality, like make it have a button on taskbar or make it become indepent from the main form (optional);

In the caller Forms:

1. Change "Application.CreateForm(FormClass,FormName)" to FormName.Show;

In the Project Options, tab "Forms":

1. Move the Form from "Available" list to "Auto-create" list (if needed);

That's it.

MDI x SDI

My project has several MDI forms. Right now I'm studying the conversion of all MDI forms to SDI, not only because Lazarus does not support MDI, but also for usability issues. I've read several sources basically stating that MDI is harmful - and for what I see in daily basis, I agree. Here I quote Joel Spolsky (from the www.joelonsoftware.com site):

Here are the usability problems people have with MDI:

* They accidentally minimize a child window, e.g. by double clicking it's title bar, and don't know what they've done. Then they think the other windows are lost.

* They get into a state where the child windows are not even visible because the main window is too small or scrolled away, and don't know what they've done. Then they think the window is lost, and choosing it from the Window list does nothing.

* They close the app when they meant to close a child window because the X's icons are so close.

There are a whole range of other pathologies. Programmers are very logical people and understand MDI quickly. Most end users just don't get it and usability on these apps is terrible.

Joel Spolsky
Wednesday, January 16, 2002

What can I say? He's damn right: been there, done that. Porting my project to Lazarus will be a hell of a excuse to get rid of MDI for good.

FPC 2.0.2 and postgresql3dyn

The Win32 binary installation of FPC 2.0.2 does not have the postgresql3dyn unit. This unit is not needed in order to compile Lazarus itself, but it IS needed by sqldb. Once Lazarus needs the FPC sources for some features, and most people have them, it's easy to solve this problem.

Considering the FPC binaries AND sources are in C:\FPC\2.0.2:

1. mkdir C:\FPC\2.0.2\units\i386-win32\postgres
2. cd C:\FPC\2.0.2\packages\base\postgres
3. make
4. copy units\i386-win32\* C:\FPC\2.0.2\units\i386-win32\postgres

Thanks giantm from #lazarus-ide channel for the help. If the step 3 does not work, probably the Delphi's make is being called instead of GNU's - if Delphi was installed BEFORE Lazarus, its bin directory is in Windows PATH environment variable. To solve it, I renamed make.exe from Delphi to make_delphi.exe; other way to do the same is using:

3. C:\FPC\2.0.2\bin\i386-win32\make.exe

As usual, YMMV.

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).