[lazarus] Compile freezes up ??

[Mattias Gaertner]

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?


Mattias