[lazarus] Compile freezes up ??

[Andrew Johnson]

TTFN
Genius(in name only)


>From: David Creelman <dave at geko.net.au>
>Reply-To: lazarus at miraclec.com
>To: lazarus at miraclec.com
>Subject: Re: [lazarus] Compile freezes up ??
>Date: 24 Oct 2002 08:38:03 +1000
>
>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....

Well as to this one.. I just figured it out.. this will not break 
compatibility. I new we didn't any extra proprty for this one. The ONLY 
reason menu's uses Forms, is to set its parent menu to nil on destroy. This 
should be done in TCustomForm.Notification anyway! All we need to do is 
remove the Form code from menus and remove controls and forms from menu's 
uses. Then On TCustomForm.Notification do

  If (Operation = opRemove) and (AComponent = Menu) then Menu := nil;

And boom. One less circle, with no compatibility lost! At least it works 
fine on my system.

(I Would commit  this right now myself, but I can't access CVS from the 
current internet connection)

Andrew

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