Wednesday, September 13, 2006

Why Delphi Win32 is important

Delphi Win32 is important because of Linux.

Right now it is one of the best options for cross-platform development. Kylix is dead (correct me if I am wrong); Lazarus is not ready yet (but it's on the way); Mono is not good enough yet (and is doomed to play catch with Microsoft .NET). Other portable options (Java/GTK/QT/etc) don't have a nice RAD environment like Delphi.

On the other hand, WINE has evolved (in the last years) enough to run most Win32 applications written in Delphi 7 or less. If the developer avoids certain problematic components, it runs 100% fine. Faster than Java, more complete than Mono, easier to code than GTK / QT / whatever. Been there, done that.

Many software solutions these days are web applications - cross-platform by design. For the few cases where you can't run in a browser, a Delphi Win32 application running under Wine is an excellent solution. This way you can please both markets easily.

Wednesday, September 06, 2006

ACBr and Wine

We are replacing our custom-made ECF (Emissor de Cupom Fiscal) component. The new versions will use ACBr. In other news, the software now runs almost perfectly under Wine. There's no speed issues - it's faster under Wine than it would be if it was written in .NET or Java.

Monday, June 19, 2006

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.

Wednesday, March 22, 2006

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.

Wednesday, March 15, 2006

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!

Sunday, March 05, 2006

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!

Thursday, January 26, 2006

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.

Tuesday, January 17, 2006

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.

Wednesday, January 04, 2006

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.