Hello,
today i make a cvs update but after make i get the following errors:

gtklclintfh.inc(31,10) Error: There is no method in an ancestor class to be overridden: TGTKOBJECT.CHECKMENUITEM(ulong,LONGINT,boolean) gtklclintfh.inc(33,10) Error: There is no method in an ancestor class to be overridden: TGTKOBJECT.ENABLEMENUITEM(ulong,LONGINT,boolean) gtkint.pp(304,1) Fatal: There were 2 errors compiling module, stopping make[3]: *** [interfaces.ppu] Error 1
make[3]: Leaving directory `/usr/share/lazarus/lcl/interfaces/gtk' make[2]: *** [gtk_all] Error 2
make[2]: Leaving directory `/usr/share/lazarus/lcl/interfaces' make[1]: *** [interfaces] Error 2
make[1]: Leaving directory `/usr/share/lazarus/lcl' make: *** [lcl] Error 2

is this a feature or a bug

greets harry

The interface spect just changed. The win32 vversion is already adapted. The gtk version needs some work.

Marc

Fixed

I broke several unnecessary unit circles. Can someone of the win32 people check, if the win32 intf compiles? My cross-compile is currently broken.

Mattias

see below

I think we are talking about the same thing. Maybe a little bit more clear:

interface
.. uses ..
LCL
.. uses ..
interface base
.. uses ..
base types

IMPORTANT:
In the following context, the "LCL" is the lazarus component library. That means the OO components and not the interface functions.

Mattias Gaertner wrote

I broke several unnecessary unit circles. Can someone of the win32 people check, if the win32 intf compiles? My cross-compile is currently broken.

Sorry, forgot to answer your question: currently it compiles.

Micha.

Mattias Gaertner wrote

I broke several unnecessary unit circles. Can someone of the win32 people check, if the win32 intf compiles? My cross-compile is currently broken.

Could you elaborate please? Did I introduce cycles causing errors in compilation? I believe I made it such that the interface compiled when I committed my stuff.

Regards,

Micha.

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.

Yes. This is bad.

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.

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.

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.

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.

Micha.

Mattias Gaertner wrote

On Thu, 27 Nov 2003 23:10:24 +0100 Marc Weustink wrote:

[snip]

Hmm...

That would require a lot of typecasting, but is better. The new situation would be

The LCL needs the baseInterface and FCL
The baseInterface needs FCL
The XXXInterface needs LCL and baseInterface and FCL

I don't see a problem here.

Marc

I think the problem is that we are acting as if the LCL and the interface are seperate entities. As if they are independent. We say: the LCL uses the interface as if the interface is a layer completely below the LCL. But it is not. Mattias already said this of course, but it took a while for me to see the 'whole picture'. Correct ways to fix it:
1) Make the interface really indepedent. This means you should be able to rewrite all the programs in examples/ without using the lcl at all, only interfacebase.
2) Regard the lcl and interface as one layer. Then placing the interface on top of the lcl will justify not being able to write those examples without the lcl, because the interface depends on it, which it does.

Mattias: "So, I think, eventually we need to get rid of the generics." I agree, and I have some ideas but I am unsure how to do it exactly.

Micha.

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.

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.

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.

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 ?

An 'as' is even stronger and the compiler already checks for TBaseMenuItem.

1. The LCL and its interfaces are full of examples of typecasting TControls to descendents.
2. Users are humans, humans make mistakes, users will typecast without check and call the interface functions. => The interface should check the type.

> - We can add function to TBaseMenuItem, so that te typecast is not > needed. Can you suggest an example?

For example GetIndex and GetParent.

Mattias

I find the current approach less readable: extra units (menutype in this case), extra definitions (TBaseMenuItem), unnecessary casting from TBaseMenuItem to TMenuItem, while we know it is a TMenuItem. IMHO, the interface hierarchy is like this:

high - lcl (delphi compatible) interface
- generic platform independant interface
- lcl itself: controls, stdctrls, etc.
low - lcl type definitions

If we adhere to this order, nothing can go wrong. Things on lower level may use things on a higher level, but only when they need to implement functionality.

If units are ordered hierachical, an user can start exploring the high lvl units and then go down, as he needs. But with unit circles, he needs to read the whole circle to understand what is going on.

I think not many users read interface uses and 'know' what's meant when he reads an interface call.

Just my 2 eurocents,

Micha.

Or a TBaseMenuItem, which is a base type.

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

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

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

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

Mattias

Nah, not complete. In the old situation an internal interface object (handle) was passed.

I will change it ...

OK.

Marc

What about replacing TBaseMenuItem with TComponent?

Mattias

Don't worry. It compiled.

By using the the uses section in the implementation section you created some circles. This is allowed, but it makes the code harder to structure and less readable. They are allowed, but IMO you should try to avoid them. If units are ordered hierachical, an user can start exploring the high lvl units and then go down, as he needs. But with unit circles, he needs to read the whole circle to understand what is going on.

Mattias

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

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. This could also have the advantage that potential users aren't going to call the interface directly because it suddenly is a 'higher' level. Everything the interfacebase can do, the lcl should be able to do. So by using the lcl, users have its full potential and power available.

This seems like my reason 2) above. In essence, what you are then trying to do, as we are partly doing now, is make H... out of everything which only the interface knows about: HDC, HWND, ... and then are synced to their corresponding object in the lcl. It does have a clear advantage also: my reason 1) is also solved, because that H... carries the information the interface needs to know about. Disadavantage is that you have all, or a lot of it, information twice.

This is true, but doesn't apply in this case if you ask me. Pascal has quite strong typing. So let's use that to our advantage to provide as much information as possible.

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

- We can add function to TBaseMenuItem, so that te typecast is not needed.

Can you suggest an example?

Thanks for your reply,

Micha.

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

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

No wonder. It is the old situation. :)
I will change it ...

Mattias

Would you care to elaborate?

Micha.

, except that the LCL can not depend on the interfaces.

Mattias

I really hoped, you would forget my note.
Probably you know, what smart linking means and how smart linking optimization is done in object pascal. In case of the LCL and especially its interfaces this will lead to very in depth discussions of a lot of functions. I think, such things should go to the devel list. I know from experience that the needed changes will be discussed furiously. Marc will not be amused and I'm no friend of such code as well.

Mattias

Speaking of interfacebase: Yes, you can do that.
But who wants to?

2) Regard the lcl and interface as one layer. Then placing the interface on top of the lcl will justify not being able to write those examples without the lcl, because the interface depends on it, which it does.

Maybe this can enlighten this discussion:
- There are 4 players: LCL base, interface base, LCL and the various interfaces
- Goals:
+ LCL base, interface base and LCL are platform independent
+ Interfaces are platform dependent
+ compile once the platform independent part,
then compile every platform dependent part separately (e.g. under linux: compile LCL once, then gtk, gnome, gtk intf) => interfaces depend on interfacebase
=> this point does not imply any relationship between LCL and an interface
+ LCL uses the interface base to talk to the real interface => interface base on same or below lvl than LCL
=> still no implication for the interfaces
+ LCL contains the logic, interface base not
=> LCL and interface base are not on same lvl
+ the LCL base are just some very basic functions
and types, which can also be moved to the FCL,
but are not. They are below all.

Ergo:
- LCL is above interface base is above LCL base
- Still no implication for the relationship of the LCL and the interfaces. Not even the implication that we have to separate them. So, the gtk intf was implemented depending on the LCL to make programming easier. This was just a decision for the gtk intf. Other interfaces don't need to depend on the LCL. For example: Someone can write a MyCL using the interfacebase and write an interface for say wxWindows.
But: No one wants to use the interface base without the LCL. The interface base is not very comfortable.

Mattias: "So, I think, eventually we need to get rid of the generics." I agree, and I have some ideas but I am unsure how to do it exactly.

Then we are two. I know, how to fix the smart linking (getting rid of the case statements and such things), but I fear the consequences.

Mattias