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

[Mattias Gaertner]

On Thu, 27 Nov 2003 22:41:10 +0100  Micha Nelissen
<M.Nelissen at student.tue.nl> 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.

Or a TBaseMenuItem, which is a base type.

 
> >>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.
> > 
> > 
> > .. 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. 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. 

Because the users should not use the interfaces, they should use the LCL.
And the LCL uses the interfaces. This way we can put all the platform
dependent code into the interfaces and all the platform independent code
into the LCL (including the logic, which is always platform independent and
always on top).
So, the interface part of the LCL is hidden behind the LCL controls.


> To me this 
> indicates that the interface is on a higher level. The specification of 
> the interface, however, does require the lcl.

It depends, how you define "LCL".
The interface part does not need to know a TCheckListBox to implement a
check list box thing. The win32api like functions are enough. (Theoretically
spoken).

 
> >>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.

Yes, and btw, this destroys smart linking. So, I think, eventually we need
to get rid of the generics.

 
> > 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.

:)
A good lib recognize misuse and warns to spot errors early.

 
> >>>- 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.

Huh? The TBaseMenuItem is part of the interface base, so its only purpose is
to make the communication with the interfaces more easier.


Mattias