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

Micha Nelissen M.Nelissen at student.tue.nl
Thu Nov 27 16:30:22 EST 2003

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.

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


More information about the Lazarus mailing list