[lazarus] Compile freezes up ??

Mattias Gaertner nc-gaertnma at netcologne.de
Tue Oct 22 05:27:28 EDT 2002


On Tue, 22 Oct 2002 10:51:34 +0200
"Marc Weustink" <marc.weustink at cuperus.nl> wrote:

> + From: Mattias Gaertner [mailto:nc-gaertnma at netcologne.de]
> +
> + On Mon, 21 Oct 2002 16:41:12 +0200
> + Marc Weustink <marc at dommelstein.net> wrote:
> +
> + > At 15:48 21-10-2002 +0200, Mattias Gaertner wrote:
> + >
> + > >The interdependent units:
> + > >There are a lot of circles in the LCL, inherited from the VCL. I
> + > >think, circles are design flaws. And I think, they can be broken
> + > >without loosing too much compatibility. But IMO each of such
> changes+ > >should be discussed first on this list.
> + > >Should we begin such a discussion?
> + >
> + > Again ???
> +
> {SNIP]
> 
> + I mean circles like: controls.pp needs menus.pp, for the only reason
> + that it needs TPopupMenu.
> +
> + I don't want to ignore the old discussion, but I hope someday the
> LCL+ will become an easy hierachy instead of the furball it is now.
> 
> If we want to have a LCL that is more or less compatible with the VCL,
> I don't see a solution to your given example. Sure, one can avoid this
> with Interfaces (non't know if abstract calles would help here). But
> then we are designing a complete new component library.

That's why we should discuss each point. You are right; every change
will break a little compatibility. But I hope we will find solutions to
minimize incompatibility.

For example menus.pp <-> controls.pp.
- menus.pp includes controls.pp in the implementation section. In the
LCL you can simply comment this out. Do we need this for some not
implemented features? 
- menus.pp includes forms.pp in the implementation section, which uses
controls.pp. TMenu.Destroy needs TCustomForm to unlink. We could add a
OnUnparentMenu event to TMenu, which is set by the parent form to handle
this in forms.pp.


Mattias






More information about the Lazarus mailing list