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

[Marc Weustink]

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.

Marc