I have (partially?) fixed this one. Stctrls used Forms, because forms had Scrollbar defines. I moved the scrollbar defines to stdctrls, and removed forms from stdctrls uses. Then I moved StdCtrls to the Forms main uses. This means that Forms still uses StdCtrls, but StdCtrls no longer uses Forms.

Andrew

_________________________________________________________________ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp

Hi all,

After successfully breaking a circle in the LCL, I checked some other circles.
There were five, that were very easy to break without loosing any compatibility.

These are at least three other, which have to be checked:

stdctrls.pp <-> forms.pp

interfacebase.pp <-> Dialogs, Forms, StdCtrls, ExtCtrls, Graphics, Buttons

controls.pp <-> forms.pp - probably impossible without loosing compatibility

Mattias

Hmm. Controls is used anyway and Controls<->Forms builds a hard join, so to break the stdctrls.pp<->forms.pp circle we must make forms.pp independent of stdctrls.pp.

I will break it tomorrow together with the interfacebase circles.

Mattias

Okay.. The Dialogs is pointless. it serves no purpose as far as I can tell, Stdctrls is used by the generic drawtext I wrote because of DeleteAmpersands, this can be fixed by moving DeleteAmpersands to the generic interfaces code. Everythings else is pretty much all my fault. And I do not know how to fix it yet.

Basically the rest is used by my generic PromptUser & RequestInput forms. To make Message Dialogs Interface Dependent, I copied the code from message dialogs into these routines so they could be overriden by interfaces, as I have started with GNOME, and planned on doing with Win32. But for the generic routines, I couldn't figure out how else to do them since the lower level functions I would have used on Win32 aren't available, so I have to use the LCL components directly just as in Dialogs, which of course create the loops. If you can figure out how to fix this please tell me! Its been bugging me since I did it, but I couldn't see any way around it, and still don't.

Andrew

_________________________________________________________________ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp

I hope you don't want to say that we use the trick to be compatible to Delphi. ;)

Hope so. :)
You know, one year ago I sent you a mail, describing how to break the LCL<->interface circle. It was a matter of minutes. But at the time it seemed just one circle out of hundreds.

Lazyness.

Maybe I should stop getting machines crashed, so that I can go back to coding :) Marc (just recovered a box from a hardcrash)

:)

Mattias

This is the bug #2196 which Andrew ment.

Mattias

:(

What's the status with 1.1?

+ From: Mattias Gaertner

[SNIP]

+ The trick circle Interfaces.pp <-> LCL:
+ I guess, only the developers know about this one and its purpose, so
+ here is the story:
+
+ The LCL is the basic component set. The widget interfaces (gtk, gnome,
+ win32) lie above the LCL and use directly the LCL units. And the LCL
+ communicates to the interfaces via the abstract TInterfaceBase object.
+ This object is created in interfaces.pp. When compiling the LCL the
+ interfaces.pp of the abstract directory is used.
+ When compiling one of the real interfaces (e.g. gtk) the abstract
+ interfaces.ppu in the lcl/units directory is deleted and a gtk-specific
+ interfaces.ppu is created in lcl/units/gtk.
+ When you compile an LCL application the compiler finds 'forms' in the
+ uses section and loads lcl/units/forms.ppu, which uses 'interfaces'. But
+ this time the compiler uses the interface specific
+ lcl/units/gtk/interfaces.ppu, which would normally be impossible,
+ because this is a forbidden pascal unit circle: forms -> interfaces ->
+ gtkint -> forms

It is not realy a forbindden circle, more an unwanted circle.

Forms reffered to iterfaces in its implementation section.

+ The advantage of this trick is:
+ - In the program source (.lpr) you don't need to add 'interfaces'. +
+ The disadvantages of this trick are:
+ - The interfaces.pp must be compiled several times to make sure,
+ that the compiler syncs all units. This is the reason, why you
+ can't add lcl and lcl/interfaces/gtk to the unitpath.

For normal apps, this shouldn't be a problem.

+ - The compilation is somewhat tricky and so the Makefiles are
+ more complicated.

True

+ - Forcing the compiler to create a forbidden pascal circle is IMHO
+ a bad example for coding.

See above.

+ I hope this was not too negative. I don't want to offend someone,
+ because of coding style. This is open source, so everyone can write if
+ he/she thinks that something can be done better.

I don't feel offended :-)

The reason for the construction as it is now is pure historical. While the project grew, more and more knowledge of the LCL was needed in the interface {*}. Since we were developing only for a GTK set, this could be compiled in one go (interface and LCL).
Problem introduced here is that one needs a compiled LCL for every widgedset. So if one wants to make an app for different widgetsets, one has to have all the different binary LCL's. With the current solution one has one LCL (and onle different interface units)

{*} And still IMO when the interface has more common functions and/or events the interface doesn't have to know anything about the LCL. And there would be no circle.

Marc

Besides some linux <-> unix things (which I don't commit because of posix stuff):

usage: dirname path
gmake[1]: Entering directory `/fpc/projects/lazarus' /usr/local/bin/ppc386 -gl -Fulcl/units -Fulcl/units/gtk -Fudesigner -Fudesigner/units -Fudebugger -Fucomponents/units -Fu. -Fu/usr/local/lib/fpc/1.1/units/freebsd/rtl -Fu/usr/local/lib/fpc/1.1/units/freebsd/paszlib -Fu/usr/local/lib/fpc/1.1/units/freebsd/inet -Fu/usr/local/lib/fpc/1.1/units/freebsd/fcl -Fu/usr/local/lib/fpc/1.1/units/freebsd/regexpr -Fu/usr/local/lib/fpc/1.1/units/freebsd/mysql -Fu/usr/local/lib/fpc/1.1/units/freebsd/ibase -Fiinclude -Fiinclude/freebsd -FE. -di386 lazarus.pp buildlazdialog.pas(283,7) Error: Argument can't be assigned to buildlazdialog.pas(284,62) Error: Argument can't be assigned to buildlazdialog.pas(702) Fatal: There were 2 errors compiling module, stopping gmake[1]: *** [lazarus] Error 1
gmake[1]: Leaving directory `/fpc/projects/lazarus' gmake: *** [ide] Error 2

This seems to be assigning to tool.cmdlineparams, which is a string property

You are right. Sorry.
But fact is, that fpc is not able to compile the LCL and the gtk-interfaces in one go.
Just copy all units into one directory and fpc will show you what it things about all this loops:

[...]
Compiling interfaces.pp
Compiling interfacebase.pp
interfaces.pp(34,21) Error: Identifier not found TINTERFACEBASE interfaces.pp(34,35) Error: Error in type definition

Right.
The problem is of course, that _if_ someone does it he got strange errors. Therefore we had to add several FAQs to make sure that no one run into this trap. And also we added Template paths to the IDE so that newbies don't try.

OTOH adding 'interfaces' to a file, that is normally auto created by the IDE is also not a problem.

I think, your statement could be misinterpreted by newbies as if we _must_ use the current construction to separate the LCL from the interfaces. This is not the case. We can compile the LCL without interfaces.pp and use only interfacebase.pp.

{*} And still IMO when the interface has more common functions and/or events the interface doesn't have to know anything about the LCL. And there would be no circle.

Why that? The LCL has its abstract interface. So, why should the interface not ly above the LCL and use it?

Mattias

Bit by bit, some of the erarlier dependencies were removed. At that time I had the idea that everything depended on everything. Besides that, I think we have now better dependencie toots :)

:-)

Marc

PromptUser and RequestInput are our own creations and have no counterpart in the VCL. So, we can do what we want. Both functions now simply call handlers instead of doing everything on their own. And because both shows dialogs, I moved the code to dialogs.pp. Andrew I renamed your TMessageBox from interfacebase to TPromptDialog. Can we join TMessageBox and TPromptDialog?

I also broke the stdctrls.pp <-> forms.pp circle by implementing it the same as the VCL do it: ugly. But it is fully compatible now.

Then I broke some minor circles, also fully compatible and moved DeleteAmpersands to the new lclproc.pas. I also accelerated this function and hope it does the same as before.

The only circles left are:

actnlist <-> forms
actnlist <-> menus
controls<->forms
the trick circle Interfaces.pp <-> LCL

Any volunteers for actnlist?

The controls<->forms circle can be broken (fully VCL compatible). But it would reduce readability, so I think we should keep it.

The trick circle Interfaces.pp <-> LCL:
I guess, only the developers know about this one and its purpose, so here is the story:

The LCL is the basic component set. The widget interfaces (gtk, gnome, win32) lie above the LCL and use directly the LCL units. And the LCL communicates to the interfaces via the abstract TInterfaceBase object. This object is created in interfaces.pp. When compiling the LCL the interfaces.pp of the abstract directory is used.
When compiling one of the real interfaces (e.g. gtk) the abstract interfaces.ppu in the lcl/units directory is deleted and a gtk-specific interfaces.ppu is created in lcl/units/gtk.
When you compile an LCL application the compiler finds 'forms' in the uses section and loads lcl/units/forms.ppu, which uses 'interfaces'. But this time the compiler uses the interface specific lcl/units/gtk/interfaces.ppu, which would normally be impossible, because this is a forbidden pascal unit circle: forms -> interfaces -> gtkint -> forms

The advantage of this trick is:
- In the program source (.lpr) you don't need to add 'interfaces'.

The disadvantages of this trick are:
- The interfaces.pp must be compiled several times to make sure, that the compiler syncs all units. This is the reason, why you can't add lcl and lcl/interfaces/gtk to the unitpath.
- The compilation is somewhat tricky and so the Makefiles are more complicated.
- Forcing the compiler to create a forbidden pascal circle is IMHO a bad example for coding.

I hope this was not too negative. I don't want to offend someone, because of coding style. This is open source, so everyone can write if he/she thinks that something can be done better.

Mattias

+ From: Mattias Gaertner

[SNIP]

+ > It is not realy a forbindden circle, more an unwanted circle.
+ >
+ > Forms reffered to iterfaces in its implementation section. +
+ You are right. Sorry.
+ But fact is, that fpc is not able to compile the LCL and the
+ gtk-interfaces in one go.
+ Just copy all units into one directory and fpc will show you what it
+ things about all this loops:
+
+ [...]
+ Compiling interfaces.pp
+ Compiling interfacebase.pp
+ interfaces.pp(34,21) Error: Identifier not found TINTERFACEBASE
+ interfaces.pp(34,35) Error: Error in type definition

Hmm.... thats new to me (I've to admit that I haven't tried it ever after it was splitted)

+ > + The advantage of this trick is:
+ > + - In the program source (.lpr) you don't need to add 'interfaces'.
+ > +
+ > + The disadvantages of this trick are:
+ > + - The interfaces.pp must be compiled several times to make sure,
+ > + that the compiler syncs all units. This is the reason, why you
+ > + can't add lcl and lcl/interfaces/gtk to the unitpath.
+ >
+ > For normal apps, this shouldn't be a problem.
+
+ Right.
+ The problem is of course, that _if_ someone does it he got strange
+ errors. Therefore we had to add several FAQs to make sure that no one
+ run into this trap. And also we added Template paths to the IDE so that
+ newbies don't try.

It is the same for Delphi if you add your VCL sources to your search path instead of your browse path.

+ OTOH adding 'interfaces' to a file, that is normally auto created by the
+ IDE is also not a problem.
+
+
+ > The reason for the construction as it is now is pure historical. While
+ > the project grew, more and more knowledge of the LCL was needed in
+ > the interface {*}. Since we were developing only for a GTK set, this
+ > could be compiled in one go (interface and LCL).
+ > Problem introduced here is that one needs a compiled LCL for every
+ > widgedset. So if one wants to make an app for different widgetsets,
+ > one has to have all the different binary LCL's. With the current
+ > solution one has one LCL (and onle different interface units) +
+ I think, your statement could be misinterpreted by newbies as if we
+ _must_ use the current construction to separate the LCL from the
+ interfaces. This is not the case. We can compile the LCL without
+ interfaces.pp and use only interfacebase.pp.

Hmm... isn't that what I was trying to tell... :-)

+ > {*} And still IMO when the interface has more common functions and/or
+ > events the interface doesn't have to know anything about the LCL. And
+ > there would be no circle.
+
+ Why that? The LCL has its abstract interface. So, why should the
+ interface not ly above the LCL and use it?

To avoid circles ?

Hmm... now you say so... since we are using an abstract interface why do we have a circle ? Maybe I should stop getting machines crashed, so that I can go back to coding :)

Marc (just recovered a box from a hardcrash)

As of this week the LCL will compile, thanks to FPC fixes commited over the weekend(by Peter I thnk) that fixed the three biggest showstopper bugs, and modifications that Mattias and myself made in Lazarus and the LCL. I haven't done a lot of testing, but most basic stuff apears to work. But Lazarus will not compile until FPC bug #2196 has been fixed, And it will not run until at least FPC bug #2056 has been fixed. I say at least because until it has been fixed we won't know if there are any other bugs which will prevent proper execution.

Andrew

Andrew Johnson wrote:

[SNIP]

Sort of off topic:

I have now finished the switch. This takes care of the duplicate TMessageBox, simplifies actual messages code, and ensures that Message dialogs can be overriden by interfaces to match the system. I have done this already for GNOME, so if Lazarus is compiled with GNOME, all dialogs will now match the GNOME default. woohoo! Oh, and I have also switched to use a more intelligent way of determining what the default button should be, and what the escape value should be. Feel free to change if things don't act the way you expect.

There may be issues yet, but there are two that might want to be considered -

1.) the actual order of buttons cannot be determined, for instance [mbyestoall, mbyes,mbno,mbnotoall]
or any other order therein will always display as [mbyes, mbno, mbyestoall, mbnotoall], I feel the programmer
should have full control over layout if wanted. Also we need to create a better way of determining what the default order should be.

2.)Gnome & Gnome enabled WM (often) automaticaly place the Message Dialogs over the main form. For most
programs this will be fine and normal, but for Lazarus it makes more sense to center on screen. So it may make
sense to use MessageDlgPos instead within Lazarus code, so as to accomplish this.

Andrew

Wheeew. you had me freaked there for a second! But nice way of handling things. We might want to do the same for InterfaceBase MessageBox too.

As for the TMessageBox vs. TPromptDialog, I am actually almost done doing this. The whole point behind PromptDialog was to have an Interface dependant way of handling messages, so that for instance GNOME dialogs could use the GNOME routines, thus making GNOME enabled Lazarus apps more GNOME'ish. ShowMessage already usess NotifyUser(atXY), which are really wrappers around promptuser(AtXY) themselves. I Just realizsed that since we do not have Dynamic arrays my current Implementation would make the MessageDlg wrappers a bit more difficult to write, so I resesigned the PromptUser routines to use a PLongint to handle the Buttons, instead of an array. Now that I have that I have started testing out versions of MessageDlg's that use these instead. When I am done TMessageBox can be deleted altogether, and we will only need TPromptDialog.

Then I broke some minor circles, also fully compatible and moved DeleteAmpersands to the new lclproc.pas. I also accelerated this function and hope it does the same as before.

Looks like it is working fine so far.. It should only affect self-draw components, this includes TSpeedButton, TStaticText, and the Property Editor. And all of the above apear to work fine for me.

Andrew