[lazarus] compile error on New Sources from cvs - FIXED
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
> 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