Compiling d:\lazarus\lcl\forms.pas Fatal: Can't find unit CUSTAPP Without comment! ????

My comment is that fpc cannot find the FCL. CustApp.pp is part of the FCL shipped with fpc. I had the same problem after renaming the FreePascal directory. The solution was to adjust the fpc.cfg and setpath.bat file. Or to restore the original directory name C:\pp (the install default).

Maybe we should rename all files to .pas, so that compiling with Delphi will become easier and we get the hints of both compilers.

There are some more "Local variable is assigned but never used" but I had not fixed these because the code looks like it is not finished yet
.
BTW I found a note that fpc 1.9.0 gives but Delphi not: "grids.pas (2482,3) Note: Local variable "Releaxed" is assigned but never used" This is wrong. The assigned value is used in an if-statement that is in a case-of branch.

Without comment! ????

G:\>d:\fpc\bin\win32\ppc386 -TWin32 d:\lazarus\lcl\forms.pas Hint: End of reading config file fpc.cfg
Free Pascal Compiler version 1.9.1 [2003/11/13] for i386 Copyright (c) 1993-2002 by Florian Klaempfl
Target OS: Win32 for i386
Compiling d:\lazarus\lcl\forms.pas
Compiling d:\lazarus\lcl\controls.pas
Compiling d:\lazarus\lcl\imglist.pas
Compiling d:\lazarus\lcl\dialogs.pas
Compiling d:\lazarus\lcl\controls.pas
controls.pas(163,17) Hint: Type "TSHIFTSTATE" redefinition controls.pas(946,19) Hint: Type "TGETCHILDPROC" redefinition Compiling d:\lazarus\lcl\forms.pas
Fatal: Can't find unit CUSTAPP

G:\>

I have uploaded a Delphi 6 and FPC 1.9.0 compatible LCL version to http://schueler.freepage.de/igvrobotik/Delphi/lcl.zip (1.6 MB). It is based on the latest changes (2003-11-14 21:24) from CVS

- All .pp files are renamed to .pas files because Delphi does not really work with .pp.
- The Messages.pp was merged with LMessages and removed.
- Lot's of "function return value may be undefined" are fixed.
- Many unused variables and unnecessary variable assignments are removed.
- The code compiles with Delphi 6 and FPC 1.9.0 under Windows. ( I have not tried it on Linux).

It would be nice, if someone can create a diff of these changes, so we can fix the LCL.

Maybe we should rename all files to .pas, so that compiling with Delphi will become easier and we get the hints of both compilers.

Mattias

Ehm, can you create a diff against CVS. Alltough there aren't changes compared to the CVS, we have local changes as well.

Marc

Ehm, can you create a diff against CVS.

Done. You can download the patch file from http://schueler.freepage.de/igvrobotik/Delphi/lclpatch.zip The patch is based on .pas files and it contains some new bug fixes.

It would be nice, if someone can create a diff of these changes, so we can fix the LCL.

The code is up to date with the only exception: messages.pp. The code is based on the last changes in LCL files on the CVS server, date: 2003-11-14 21:24. I have updated the LCL directory on my harddisk at 2003-11-14 22:30. And there were no further changes.

If someone provides Delphi compatibility patches why shouldn't they be incorporated into the lcl?

unit AvgLvlTree, 4th chunk of you patch

Its in the beginning of your patch

It's a "known" issue with these directives. One way to solve it is something like:

{$ifopt warnigns on}
{$define warnings_were_on}
{$warinings off}
{$endif}
do your things
{$ifdef warnings_were_on}
{$warinings on}
{$undef warnings_were_on}
{$endif}

That's a lot of ifdef.

Eeek, thanx

Marc

Yes, I know. But: Delphi compatibility could bring the lcl to a broader audience and at least for Kylix developers the lcl is usefull to write GTK applications. Further, a broader audience could also gather new developers for the lcl. My personal opinion is that an open source projects should accept all patches if they aren't too strange. Of course, nobody expects that the current lazarus developers spent time into keeping the lcl compilable with Delphi/Kylix. But if somebody provides patches why not incooperating them?

Just an example: sometime ago, someone contributed patches to compile FPC (the compiler itself) with Delphi5. This is pretty useless because Delphi often IEs when compiling FPC or creates a non working FPC. If the created FPC works, it's two times slower than an FPC compiled with FPC. Nevertheless, we applied these patches. Why? Well, it's the way how OSS development works. If a patch affects core functionality of a project, it's another story but it doesn't seem to be the case here.

Of course, finally it's your decision, but just my 2 (euro) cent ;)

----- Original Message -----
From: "Andreas Hausladen"

> Ehm, can you create a diff against CVS. Done. You can download the patch file from http://schueler.freepage.de/igvrobotik/Delphi/lclpatch.zip The patch is based on .pas files and it contains some new bug fixes.

I have updated the lclpatch.zip file with the newest changes (2003-11-15 14:21 downloaded 18:40) in LCL and I have removed many Delphi dependend IFDEFs.

Andreas

the final

> conclusion is that the LCL won't support Delphi. If someone provides Delphi compatibility patches why shouldn't

they be

incorporated into the lcl?

Patches to make the LCL and FPC meet Delphi compatibility is fine. These patches were to make the LCL work within Delphi. We aren't developing the library to be used with Delphi but to be used with FPC.

___________________________________________________________ Sent by ePrompter, the premier email notification software. Free download at http://www.ePrompter.com.

That is already fixed in the current development compiler (1.9.1)

Peter

Thanx, fixed.

There was possibly more wrong here. In the new DC, the bitmap wasn't deselected before destroying the DC.
It's not documented if this is allowed, but to be on the safe side, deselecting (== selecting the old object) does no harm.

Marc

Hmmm.. it seems that I forgot so send my earlier reply.

OK, thanks for it, this one looks a bit better, however....

We (thedevels) have had a litle discussion about it, and the final conclusion is that the LCL won't support Delphi.
The LCL is written to be used with the FPC compiler and environment to allow people to build Delphi-like code WITHOUT using Delphi.

Ofcoarse were it the empty function results, unused vars etc. concern, we will look at every patch separately

Marc.

BTW, while having a quick look at the first 10% of the patch I noticed 2 errors.

1) When comparing pointers, they are unsigned

  function ComparePointer(Data1, Data2: Pointer): integer;
  begin
-  if Data1>Data2 then Result:=-1
-  else if Data1<Data2 then Result:=1
+  if Longint(Data1)>Longint(Data2) then Result:=-1
+  else if Longint(Data1)<Longint(Data2) then Result:=1
    else Result:=0;
  end;

Longint should have been a cardinal here

2) The handling of compiler directives
What if warnings were off ?

+ {$IFNDEF FPC}{$WARNINGS OFF}{$ENDIF}

      property Owner: TCustomListView read FOwner;

+ {$IFNDEF FPC}{$WARNINGS ON}{$ENDIF}

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

Where have I used such a function? I cannot find it in my code.

You are right. But I have Warnings and Hints allways on, so I had not notified this "error".

We (thedevels) have had a litle discussion about it, and the final conclusion is that the LCL won't support Delphi. The LCL is written to be used with the FPC compiler and environment to allow people to build Delphi-like code WITHOUT using Delphi.

You know what this means for me. Now I have two opportunities: to fork or to stop development on the Delphi port. For the first time I will choose the later...

One last bug fix because it is not that easy to find.

interfaces/win32/win32object.inc:
Function TWin32Object.IntSendMessage3(LM_Message: Integer; Sender: TObject; Data: Pointer): Integer;
  Procedure DrawOwnerButton;
      ...
      BitmapHandle:=TBitBtn(Sender).Glyph.Handle;
      ...
      DrawText(_HDC, LPSTR(TBitBtn(Sender).Caption),
        -1, rcItem, TextPosFlags);
**  DeleteObject(BitmapHandle);   <--- this line must be removed
      DeleteDC(hdcBitmap);
   end;

With regards,

Andreas Hausladen

C++Builder can use Delphi classes, but not the other way around. The Delphi compiler has a special switch to generate C++ .obj object files and .hpp header files.

HTH,

Micha.

Just to weigh in on this issue. I'm currently using Delphi (5) and Cbuilder(5) in my development, which has releases every month, and usually mid-month as well. To do development we use Delphi to do the internet, pdf, and interface stuff, and cbuilder to do the calculations and data stuff. To do this, we compile the cbuilder side into either a release (which means it compiles the Delphi code as part of the project) or as a dll which is used only for development of the Delphi side.

I was originally interested in Lazarus and FPC because of it's multi platform ability. To me, making it Delphi compatible means giving me more options. (I can go to either Delphi or FPC/Lazarus). I like that. I ended up ignoring the FPC for a couple of years, due to the large differences between the compiler syntaxes. (I know you don't believe me, but I'm the one who would have to end up re-writing everything). It would be very useful to me if the FPC was able to compile the VCL code. Then I would be able to move to the LCL in a gradual manner. (There is too much to do all at once, and insure it is bug free).

Just thought you might like to hear from someone quietly rooting you on, from the trenches.

Chris Bruner

(Hmm, not MSVC++?)

But even then, that is still one more as FPC.

Of course FPC can link easy to gcc libraries, which is also a big plus. I'm not saying FPC hasn't got something to balance that, but the fact remains.

Compiling the vcl is one of the goals for 2.0 :)

wow I seem to have missed all the fun. :)

well here is my long winded take on the subject(not to reopen the issue).

1.) Why should it be ported to Delphi?
well several answers here mentioned,
a.) another compiler to test and find errors with
b.) closer compatibility with vcl.
c.) larger programming community
d.) well, why not its Open Source, anything should go.

these are not bad reasons and not entirely incompatible with the goals of LCL and lazarus assuming they are true/work out this way. But that brings up the next subject, why not? why _shouldn't_ we accept this sort of patch?

2.) Why shouldn't it be ported to Delphi
I have heard and have several reasons I have my own where I can see why not -
a.) The LCL is an FPC project, more specifically -

if the LCL is a FPC project it should take
advantage as much as possible of the programming
advantages offered by FPC, in my opinion not only
should the LCL and lazarus sources use ObjFPC as
much as possible, they should make use of the
extensions offered by FPC where it makes for more
readable code, and where it makes for easier
maintenance etc.

Eg is in the GraphMath unit I
made use of operator overloading to simplify bezier math. this is not only more readable code, it is less then 1/4'th of the size required in Delphi. properly ported to Delphi not only ensures a larger
code-base but less understandable code, if this
project were always intended to work with both
making this sort of sacrifice would make sense, but it was not and has not, and converting to Delphi
means a step backward for something not even part
of the intended goals.

b.) porting to Delphi does _not_ ensure better VCL compatibility

Porting to Delphi means only a few things, the LCL now works with Delphi so long as you do not use the VCL at all, or change the names of all the LCL to
be incompatible with VCL names so they don't
conflict.

If we wish LCL to work with Delphi properly we must change the names, to those like in kylix, so not
compatible, and either do this only for the Delphi version, which means FPC LCL and Delphi LCL apps
are not source compatible without ifdefs etc., or
for all apps, which means old LCL apps need to be
changed, and Delphi VCL apps _still_ need more
modifications just of files, not to mention all
controls and back-end differences ensured by the
very cross-platform nature of it. Both solutions break the very concept of LCL portability.

c.) maintainability
if changes are kept within ifdef's this adds huge
overhead to the complexity of code, if it were
stored in includes, then due to the nature of the
current layout whole files will need to be
duplicated for minor changes, either case adding a great deal of problems to maintainability
especially to those who currently work and develop Lazarus and the LCL, but have no interest in the
Delphi port for themselves,

So either the current developers must also
maintain this additional code meaning less
time for overall development, or they must leave it to other people to upkeep, which in an open source environment is not assured, and given the large amount of code currently in the LCL, it might be months between times LCL even would compile with Delphi anyway.

Basically IMO, meaning such a port cannot be very official, or supported, which for the most part seems a waste of time and space for the I think the overall complexity and problems caused outweigh any small benefit gained from it. If this is wanted it should be maintained by those who want it, as a set of patches against the LCL. I am not against people doing this, and maybe in the process finding non-compiler specific bugs, or minor inconsistencies which don't affect good FPC compatibility that can be committed directly to CVS, but the bulk of the changes suggested are not worth it and will cause far to many headaches long term to do much good as part of the LCL, however as kept as a separate set of patches, against specific versions or dates of CVS, it ensures those who desire this, can get it and know it should work with specific versions.

there is more, but I think thats a good enough set of reasons why not - inability to take advantage of most of the improvements FPC has to offer, complex, harder to maintain, breaks consistency between apps, makes porting harder.

when it comes down to it the problem should be easy porting of Delphi apps to Lazarus. Due to various issues they _cannot_ be fully compatible, and moreover, often times (for instance lfm/lrs vs dfm) cannot be shared, so even when a project is intended to be shared, much code cannot be, trying to make as much as is possible shared is good, but easy porting should be more important. if all the important feature sets are available, and wizards and guides are available to simplify the process, porting should be rapid and easy, even if the LCL is say only 75% compatible.

Lazarus to Delphi porting doesn't make a whole lot of sense imo, we are working on an alternate IDE and backend, not a clone I don't like everything in Delphi or the VCL, many things I would prefer done differently, should we make Lazarus and the LCL compatible just for compatiblities sake? I am more prone to lean toward compatiblity but not if/when we can do it better. So it shouldn't be the focus, and when patches to make more compatible don't conflict or make more complex things better done other ways, great, and apart from win32 specific stuff, there is no reason that if ways were found we couldn't get and stay 90% compatible, but it shouldn't be the main goal, the portability, ease of use, stability, and total available feature sets should be.

Frankly, even all Delphi's are not compatible with each other. Delphi 1 Delphi2 Delphi3 Delphi 4 Delphi 5 Delphi 6 Delphi 7. NONE of them are fully backward compatible, just mostly. A delphi 7 app can be made to work with Delphi 6 with porting, but porting back further becomes more and more complex to where porting to D1 is
lazarus be 100% compatible with all versions when even they aren't? When the LCL can improve over D7 or earlier or whatever, for the most part it should, but compatibility just for compatibility sake should never be the driving reason behind the LCL.

end ramble/rant :)

Andrew

As far as I know, Delphi can only link to C++ Builder, not to e.g. MS-Visual C or GCC C++, but I am not 100% sure.

Michael.

Marco van de Voort wrote

Only other major thing I can think of is that Delphi can link to C++,

Really ;)? It can link only to C++-Builder.

and FPC needs the C++ to be C level wrapped first.

A lot of subsystems (like packages , variants and widestrings) aren't 100% complete in FPC.

For the rest FPC is complete except the non-portable dispatch interface.

Only other major thing I can think of is that Delphi can link to C++, and FPC needs the C++ to be C level wrapped first.

Wow indeed.

That saves me a lot of time. :)

Maybe a few additions:

The LCL is based on the FCL and the RTL of FPC.
At the moment, it is possible with less than a hundred IFDEFs to support the Delphi units, but this will become a mess, as soon, as the LCL supports threads, widestrings, better localization, dynamic libs and more platforms. So, in fact, the LCL is bound to the units provided by FPC.

According to the mails, the main reason to support the Delphi compiler, is to use the LCL with existing Delphi code, which can't be compiled with fpc. My question: What features are not supported by FPC 1.9, are portable and can be used with the LCL?

Mattias

You have to distinguish between this patch and the idea behind the patch.

The idea: make LCL compilable by the Delphi and FPC compiler. Possibilities:
- Add a lot of IFDEFs (like the patch)
- convert the ObjFPC mode to Delphi mode

The first makes the code less readable and less maintanable. IFDEFs are evil.
Iff we support the Delphi compiler, then it has to be done with the second alternative. But this means of course, we will loose the unambigious objfpc mode and it's very useful pointer arithmetics.

The patch also contains some "beautifications" of unit names (Lcl instead of LCL). Our normal naming scheme is either to write abbreviations lowercase or uppercase. Only words are written lowercase with initial letter big.

And some other minor things, that needs fixing. (Marc mentioned some items).

This is why the patch itself is not applied. It would cost too much time fixing.

I will write something about the idea itself in another mail...

Mattias