[lazarus] compile error on New Sources from cvs - FIXED

[Mattias Gaertner]

On Thu, 27 Nov 2003 23:10:24 +0100  Marc Weustink <marc at dommelstein.net>
wrote:

> At 22:41 27-11-2003, Micha Nelissen wrote:
> >Mattias Gaertner wrote:
> >
> >>On Thu, 27 Nov 2003 21:38:25 +0100  Micha Nelissen
> >><M.Nelissen at student.tue.nl> wrote:
> >>
> >>>You've made a good point here. However it has problems:
> >>>1) It assumes that all interfaces need the same information for doing 
> >>>the same thing, so we can pass exactly that information. This
> >assumption >>is false as proven by recent CheckMenuItem. If, and I hope
> >when, the qt >>interface is going to be implemented it may need other
> >kinds of >>information currently not passed through the parameters.
> >>
> >>I never assumed, that we pass all needed information as direct params. 
> >>Only the needed information. The interface just need a menu component
> >and >can retrieve the rest. For example: By passing a TMenuItem instead
> >of a >TBaseMenuItem, the gtk interface does still not have all the
> >information >it needs. But it can retrieve the rest. So, replacing this
> >parameter >type, will only save a few lines of code in the win32 intf.
> >
> >It wasn't about these parameters in particular. See: we already 
> >compromised on this function by 'exposing' the lcl object to it. If we 
> >follow correct OO-design, we should only pass an HMENU and an index or 
> >something like that.
> 
> I dont see what correct OO has to do with that.
> 
> >>>2) All these calls should be reported back. So CheckMenuItem not only 
> >>>checks the menuitem in the interface, but it should also report back to
> >
> >>>the lcl that it has checked the menuitem.
> 
> I do not agree with that. That is one of the reasons why I removed the 
> bChecked/bEnabled boolean. It is just a call to the interface to update
> the interface, not more. The LCL logic is in the LCL only.
> 
> >>.. and the LCL will check and react and call the interface again.
> >>This will distribute some platform independent logic over the LCL and
> >the >interfaces.
> 
> Indeed
> 
> >>The interfaces should be what they are named: just interfaces
> >>between the LCL and the widget set. If we say, that the interface is on 
> >>the same lvl as the LCL, it implies *all* interface functions are on the
> >
> >>same lvl. According to your example of the checking of a menu item: 
> >>calling the interface function FillRect on a shared bitmap handle should
> >
> >>unshare the bitmap. Just as the LCL does when you use the LCL FillRect.
> >
> >Yes. This is bad.
> >
> >>>These two reasons combined, mainly reason 1 though, I'd still vote for 
> >>>the 'hideous' way, putting the interfacebase above the LCL in the
> >hierarchy.>
> >>The LCL uses the interface base. It can be above or on the same lvl, but
> >
> >>never below.
> >
> >The LCL doesn't use the interface in it's specification. Seeing the LCL
> >as a black box, the interface never appears in any diagram. To me this 
> >indicates that the interface is on a higher level. The specification of 
> >the interface, however, does require the lcl.
> >
> >>>This could also have the advantage that potential users aren't going to
> >
> >>>call the interface directly because it suddenly is a 'higher' level.
> >>
> >>What do you mean ?
> >
> >Never mind I think; the argument doesn't work because users will look at 
> >the source code of the lcl and see the interface being used there.
> >
> >>>>- the interface functions can also be used by the user. Even if we
> >say:>>>Plz don't do. People will do.
> >>>
> >>>Yes, this is unavoidable indeed. But how does it relate to unnecessary 
> >>>casting?
> >>
> >>1. The LCL and its interfaces are full of examples of typecasting 
> >>TControls to descendents.
> >
> >This is mainly due to use of generic messages which can be valid for any 
> >type of control, hence TControl.
> >
> >>2. Users are humans, humans make mistakes, users will typecast without 
> >>check and call the interface functions. => The interface should check
> >the type.
> >
> >Partly agree, however: people who blindly typecast A to B without
> >thinking don't deserve help.
> >
> >>>>- We can add function to TBaseMenuItem, so that te typecast is not
> >>>>needed.
> >>>
> >>>Can you suggest an example?
> >>
> >>For example GetIndex and GetParent.
> >
> >Now I understand. But this is ugly because you are looking at the code of
> >
> >the interface and deciding and that basis what functions to be in 
> >TBaseMenuItem which is a bad reason imho.
> 
> OK, now I got curious about the new changes, so I got the latest cvs....
> 
> YUCK !
> 
> I don't think this is the way to go. Now, if the interface gets extended 
> with mode direct calls, we can add a TBase... for every
> TComponent/TControl etc we need.
> 
> OK, what happened.
> 
> The LCL needs the baseinterface..
> The baseinterface needs the LCL..
> 
> That means problems. Sure you can introduce all kinds of base classes, but
> 
> how would you do this with a TBaseControl and a TBaseWinControl ?
> If we are going to introduce dedicated interface classes, it starts to
> look like a discussion we had a few years ago.
> 
> Seen the latest problems and implications, I wonder if we should continue 
> the last changes we made. IMO, we should undo it and try another route.

What about replacing TBaseMenuItem with TComponent?


Mattias