[lazarus] Compile freezes up ??

[David Creelman]

On Wed, 2002-10-23 at 19:15, Mattias Gaertner wrote:
> On Tue, 22 Oct 2002 07:52:16 -0400
> "Andrew Johnson" <aj_genius at hotmail.com> wrote:
> 
> > On Tue, 22 Oct 2002 11:25:47 +0200
> > "Mattias Gaertner: <nc-gaertnma at netcologne.de> wrote :
> > >
> > >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]
> > > > + [...]
> > > > + 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.
> > >
> > 
> > Menu's..back before they were started to be implemented properly, were
> > based on TWinControl. I think this is why the uneeded uses. It is
> > probably just a little left over include on account of that.
> > 
> > TMenu.Destroy needs TCustomForm... why again? Okay.. I see the need.
> > But I think I agree on this one. Though I am not certain about the
> > needed extra property(yet).
> 
> Does anyone know a better solution or think that this solution will
> break compatibility too much?

On second thoughts, if we are aiming for Delphi compatibility, and this
breaks aspects of that compatibility perhaps it's not such a good
idea....

When will fpc 1.1 be ready ?

> 
> 
> Mattias
> 
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives