That's the problem: the LCL does not really emulate. It makes porting easy. So, it provides most commonly used functions of Delphi applications. The LCL does not and can not guarantee, that they will work as the winapi documentation. For example a function creating a win32 api button does very different things in the gtk. Because most Delphi applications don't care for the details, the LCL work. That's the whole magic.

By using the real messages.pp (and the other win32 api units provided by fpc), one can use the real stuff. And this way a developer can write programs that are win32 specific without noticing. Of course, if a developer wants to write win32 specific stuff (like the win32 intf itself), he needs the real stuff. Therefore I applied the nonwin32 workaround. I just wish, there would be a better way, so that people wanting to write platform independent code can notice win32 specifics. But I don't know no better way. So, win32 developers have to live with it.

Mattias

If you consider messages.pp as win32 api unit I would suggest to remove the references to it in the common lcl code and replace it by lmessages.pp.

Done.

Mattias

In my Delphi port I have removed the Messages.pp and moved it's content to LMessages.pp.

At the moment I try to re-port the Delphi port to FPC (almost complete). This will bring lots of small bug fixes to LCL.

Regards,

Andreas Hausladen
(JVCL developer)
(http://www.kylix-patch.de.vu)

Andreas Hausladen wrote

In my Delphi port I have removed the Messages.pp and moved it's content to LMessages.pp.

Simply delete messages.pp for win32.

Hi
with today snapshot of Lazarus there is problem with compiling with FPC1.9

compiler show error:

messages.pp(35,33) Fatal: Circular unit reference between MESSAGES and
LMESSAGES

problem is with unit lMessages in section USES

{$ifdef win32}
{$ifndef ver1_0}
,messages
{$endif ver1_0}
{$endif win32}

I think is not need, no one declaration from MESSAGES is used if LMESSAGES and this cause curcular unit reference
this should be change MESSAGES to WINDOWS:

{$ifdef win32}
{$ifndef ver1_0}
,windows
{$endif ver1_0}
{$endif win32}

Darek

Mattias Gaertner wrote

This means the LCL is not any longer really platform independent. :( OTOH you can now write win32 specific applications easier.

Why? messages is a win32 specific file which is provided by lazarus for other platform. It's like another couple of win32 functions you emulate.

thats not work under FPC1.9
LMESSAGES have declarations :

  TLMSize = TWMSize;
that is declared in MESSAGES and in WINDOWS

I've try remove MESSAGES and added WINDOWS and all work OK

Darek

Simply delete messages.pp for win32.

Yes, this would be the easiest way for a LCL developer but it is no real solution. Or would you say to a customer: "Please delete a file for a successful compilation" ? And what is if the the developer wants to migrate to Linux? "With" the deleted file he must download the LCL again if he has not backuped the file. I think the solution I've chosen for the Delphi port is better than deleting a file.

BTW: I have successfully ported the Delphi port to FPC 1.9.0

No. The final solution is to move the messages.pp to the lcl/nonwin32 dir, however the lazarus developers didn't do this yet.

Not allways, only this time.

One of these guidelines might be helpful: - Don't use includes (all in one file); example: CLX from Borland

This will be a pain to maintain. THere are even some other files on my whishlist to get splitup in several .inc files.
Working on your own on one big file is ok, working with others often result in conflicts during merge.
Besides that, it is often hard to find where several routines are.

- Use #ifdef "target" for platform specific things

Thats already the case where necesary. Further, sometimes different inc files in platform dependent dirs are more readable than pieces of code full of ifdefs.

- One person is responsible for a file (it seems that the lcl stuff is managed by different persons)

This will conflict with your first statement. Now only fewer ppl kan maintain it.

- Use .pas extension only

What has that to do with it. I found the idea behind it as Mattias explained.

Marc

... and to fix the Makefile ...

however the lazarus developers didn't do this yet.

I did.

This means the LCL is not any longer really platform independent. :( OTOH you can now write win32 specific applications easier.

Mattias

The current thread shows that there a always problems with includes, paths, circular refereces etc.

One of these guidelines might be helpful:

- Don't use includes (all in one file); example: CLX from Borland
- Use #ifdef "target" for platform specific things
- One person is responsible for a file
(it seems that the lcl stuff is managed by different persons)
- Use .pas extension only

@Andreas Hausladen:
Is your lcl solution the offical solution? Who is responsible for the "old" stuff (update, maintenance, etc)

One of these guidelines might be helpful: - Don't use includes (all in one file); example: CLX from Borland

This would be the best solution for the Delphi code navigation problem with include files.

- Use .pas extension only

Is LCL should be compilable by Delphi this is a must.

@Andreas Hausladen: Is your lcl solution the offical solution?

No. It is only in my opinion a better solution than saying developers to delete a files to get the LCL working under Windows.

Who is responsible for the "old" stuff (update, maintenance, etc)

What do you mean by "old" stuff? Do you mean the Delphi LCL port is the new LCL? No, I think the Delphi port should be incorporated into the original LCL or visi versa.

There are no problems with such includes.

- Use #ifdef "target" for platform specific things

Only readable for 2 targets.

- One person is responsible for a file (it seems that the lcl stuff is managed by different persons)

we have no full time employees and no one knows everything.

- Use .pas extension only

That can be done. Although it's only important for FPC to Delphi porting, while Lazarus is quite the opposite direction.

Mattias

If you consider messages.pp as win32 api unit I would suggest to remove the references to it in the common lcl code and replace it by lmessages.pp.

----- Original Message -----

I can understand that you want to port code from Delphi/Kylix to Lazarus

I've join to Lazarus and some times help develop FPC because this is my road to other platform like Linux, BSD and so on. Because I have half million lines of code in Delphi , when I try port it to Lazarus I must do more and more changes. Thats my opinion to achieve 99% compatibility with Delphi, that my work will be easer. Of course FPC and Lazarus can do more , but not not less.

On world is much code in Delphi, ready and free. If Lazarus won't be compatibility with Delphi all this code will be closed for Lazarus programmers.

Darek

_________________________________________________________________

Only in Delphi mode.
In objfpc mode comparing function results needs FOnCompare() = AValue(). FOnCompare without brackets is always the TMethod/Pointer.

Some features of FPC are better than Delphi's but Delphi also has features FPC does not have. Another example is the event assignment where I found FPC syntax better than Delphi's. Obj.OnClick := {$ifdef ;

Mattias

Sure. Sure. Sure. What is the aim ? Put the Delphi/Kylix *.dpr file into fpc+lcl ( without source modification :-) ) and get the win32/linux exe file.

linux RAD?

sorry, not simple words.

How about "Easier Linux Software Development"

or

rapid application development on linux.

or

an opensource alternative for cross platform rapid application development on windows and linux/unix.

It would be nice to have a replacement of the Borland Delphi/Kylix environment for Win32 and Linux which is neraly 100% compatible.

Perhaps it would be nice, but in my opinion open source projects should not try to mimic existing commercial programs and even less to be a 100% compatible replacement. One of the nice things of open source projects is that you can include whatever features you wish. And if this breaks compatibility with the commercial program no problem, people can decide if they want one or the other. I would like to see Lazarus to go beyond what Delphi/Kylix can do and not to get limited to just a free version of these two. It is enough if you can easyly port stuff from Delphi/Kylix to Lazarus, no need for the other way.

Just my 2 cent.

- Having source for compiler and RAD, being able to customize. (for embedded, special purposes, or newer windows versions)
- Not requiring OS patches on linux, supporting near all distro's.
- Supports *BSD and some other OSes.
- In the future multiple processors, and e.g. Mac OS X support. (and no, I don't think Delphi going .NET will do much for that, M$ will effectively block that)
- Continued development on the win32/x86 OS and CPU, and not freezing that in favour of .NET.
- (on *nix): more larger part of the total code available in nice Pascal source.

etc etc.

----- Original Message -----
From: "Florian Klaempfl"

Why? Delphi has the "great" VCL and CLX ;)

The great is only for VCL. The CLX is a pain in its original state. And it depends on Qt 2.x while Qt 3 is out for a long time.

----- Original Message -----
From: "Mattias Gaertner"

> I will extend my converter program to restore the .pp file extensions. As > this would keep the fpc source clean of Delphi influence. Pardon?

I've written a converter program that converts the Delphi LCL port to FPC LCL conventions. For example all LCL Delphi files in the LCL root have a filename like LclXxxxx.pas. This was necessary because Delphi already has a Forms, Graphics, Controls, ... unit.

----- Original Message -----
From: "Marc Weustink"

I know this. But as Delphi needs an @ operator for a comparison fpc does not need one. Maybe I should write
{$ifdef FPC}
  if FOnCompare = AValue then Exit;
{$else}
  if @FOnCompare = @AValue then Exit;
{$endif}
Here FPC's syntax is in my eyes ambigious because if AValue is a function with no arguments it could be a function call.

Some features of FPC are better than Delphi's but Delphi also has features FPC does not have. Another example is the event assignment where I found FPC syntax better than Delphi's. Obj.OnClick := {$ifdef ;

There is no reference to Delphi or Kylix in this answers (just like I would answer the question myself). So lets asume the Lazarus developers see it the same way as you and I do. Where is the need for (100%) Delphi compatability? I just stated that I would prefer nice new features in Lazarus over any compatability. I can understand that you want to port code from Delphi/Kylix to Lazarus. I just don't see the need for the other way. Can someone enlighten me? Or is it just that Borland messed up Kylix and people want their Delphi code to run on Linux? If this is true than I don't think that they really understand what opensource stands for.

No. FPC won't do a function call in any case when compiling this in objfpc mode even if AValue returns a procedure variable. If you want to call AValue do
if FOnCompare = AValue() then Exit;
This is very Cish but it makes procedure variable code much more readable and less ambigious. However, I never tried if FPC handles correctly a procedure variable call returning a procedure variable and call this one, i.e.
if FOnCompare = AValue()() then Exit;

:)

Some features of FPC are better than Delphi's but Delphi also has features FPC does not have. Another example is the event assignment where I found FPC syntax better than Delphi's. Obj.OnClick := {$ifdef ;

Compiling this with -Sd and you don't the @ ;) However I know this isn't an option for the lcl.

Pardon?

Mattias

The current thread shows that there a always problems with includes, paths, circular refereces etc.

The problem is simply that the fpc 1.9.x win32 rtl comes with a messages unit which wasn't the case in 1.0.x.

One of these guidelines might be helpful: - Don't use includes (all in one file); example: CLX from Borland

Really :)? I just imaginge the FPC system unit with ~20 supported targets having 100k lines ...

- Use #ifdef "target" for platform specific things

No. Too much $ifdefs are always a sign for a bad design.

- One person is responsible for a file (it seems that the lcl stuff is managed by different persons)

This is not possible for open source projects.

- Use .pas extension only

The primary target of the lcl isn't delphi.

Sorry for my irony but all these points are against all things we learned the last 10 years when working on FPC. And FPC isn't a small project, recently I generated some statistics about the FPC cvs. The whole FPC/lazarus cvs tree is 3.5 Mio lines of code, so FPC/Lazarus isn't a small sized project :)

----- Original Message -----
From: "Florian Klaempfl"

The LCL isn't QT either ;)

And that is the reason why I'm interested in LCL. LCL is a "native pascal" framework.

Andreas

----- Original Message -----
From: "Mattias Gaertner"

> - Use .pas extension only That can be done. Although it's only important for FPC to Delphi porting, while Lazarus is quite the opposite direction.

I will extend my converter program to restore the .pp file extensions. As this would keep the fpc source clean of Delphi influence.

Florian Klaempfl wrote

The primary target of the lcl isn't delphi.

It's a great pity !!!

Why? Delphi has the "great" VCL and CLX ;)

The LCL isn't QT either ;)

Ack. But Borland Delphi is the reference. There is no doubt.

For those who wonder... this is why ifdefs make things unreadable

-  if FOnCompare=AValue then exit;
+  if {$IFDEF
 then exit;

Marc

It would be nice to have a replacement of the Borland Delphi/Kylix environment for Win32 and Linux which is neraly 100% compatible.

Ack. But Borland Delphi is the reference. There is no doubt.

Can you exlpain to me (in simple words, please) why there is any need for Lazarus?

I won't vote for that.

Although it's only important for FPC to Delphi porting, while Lazarus is quite the opposite direction.

Marc

Indeed.
We are trying to be as compatible as possible to the VCL to make porting from Delphi to Lazarus easy. IMO the LCL isn't a replacement for the VCL. For the win32 target the VCL does a better job then the LCL, since we can't include all specific win32 features.

Marc

Do you mean compatible to the the VCL, or compatible between win32/linux/... or compatible with the Delphi/Kylix IDE?

Mattias

Hi There I wass a bit behind on my mail and worked throug about 200 Lazarus emails today. and the thing that grabed me the most was this thread on the LCL and compatibility with Delphi.

Here is my thots on the matter and I may revlect some points that other people made.

I THink it will be a good thing if the LCL can be used with Delphi and or Kylix because there are (Currently) mush more Delphi and Kylix developers that there are Lazarus developers. If the LCL can be almost 100% compatible with Delphi (In the sence that you can compile Delphi Code with Lazarus without changing code) it will be Excelent.

I Agree that Lazarus to Delphi conversion is maybe not that importent. but if it can be made visible it will be Great. for Example Name units that is Lazarus specifiec with laz as a prefix. then you know that if you use this units the project will not compile in delphi or kylix. if the unit do not start with this is should be compatible either way.

We are faced with more and more competition from tools like VB and Visual studio .NET and it seems that the Delphi comutity is shrinking or not growing as fast as the competition. I think we should stand togather with Delphi/Kylix and Lazarus rather than float apart. So if Delphi compatibility will not limit Lazaras I think it should be strived for. If there is More added than delphi can profide just make it clear that by using the extra futures it will not work in Delphi

Thank any case to all the controbuters for a wonderful product named Lazarus. I hope to see it grow to a even better and Mentionable alternitive for even comercial development in the future.