Why that complicated?

We want to enable/check a menu item, and not to emulate the win32 api. If the win32api function does not do, what we need, then we should simply rename the interface function (e.g. function
EnableOrCheckMenuItem(AMenuItem: TComponent; EnableCheck: boolean): boolean).
The win32 intf can then simply get the parent handle.

Mattias

Nooo...please, that's an ugly hack imho. TMenuItem's have a MenuIndex right? So why don't we pass that around? Remove the ugly Command, and use an index for positioning. Then it's easy in gtk and win32.

Regards,

Micha.

Directly?
The above statements are O(1), while the gtk way needs O(n).

(Yes, I know, this is irrelevant. The gtk needs this time internally anyway.)

Mattias

You don't have to go throug the LCL here. You can access the children of the menu directly

The LCL converts the request into a win32api function call and the gtk interface converts it back. ;)

See my other mail, i don't think this is the way.

Marc

You don't break compatibility by adding extra functionality as long as you also support the original functionality.
What functionality the LCL uses doesn't matter, that won't break anything.

2) Implement a custom function. It can do whatever we want it to. Since it's obvious ;) by now we don't want 1), we'll take route 2). We should change the function name to EnableAMenuItem, as mattias suggested.

To me it isn't that obvious yet.

Shall I make the necessary modifications, or have you already begun, marc?

I already made some changes for option 1.

At this moment it might look like only needed for menus, but I think it implies more. By just adding another function we aren't finished. Today I looked at the winapi unit and a noticed that it is already polluted with non winapi functions. This is misleading. IMO the winapi unit should only contain winapi compatible functions. All others, including the new enablemenuitem should go to another (lclapi ?) unit. About naming, I don't think EnableAMenuItem is a good name. IMO LCLEnableMenuItem would be better.

So I would suggest to clear this first before doing some implementation.

Marc

It seems, my sylpheed can't handle the eudora bugs. One of us has to find a better mail client. ;)

Of course. But we should try to make writing new interfaces easier.

In the case of synedit: We already support it. The interfaces provide common winapi functions (not 100% compatible, but at least the most common flags and features) and the "too win32 specifics" are ifdefs in the synedit code. LCL makes porting easy. It does not emulate the win32 api.

On the other hand, why not introducing separate CheckMenuItem(TMenuITem, Boolean) and EnableMenuItem(TMenuITem, Boolean) functions.

I vote for it. Although I think we should rename them unique. To make searching for a function easier.
We have to change some win32api functions anyway, otherwise smartlinking will never work smart.

What mechanism had you in mind ? Like the winapi, all flat function wrappers around the interface object ? Or are we going back to calling interfaceobject methods directly ?

I just think, that "Enable Child MenuItem Number i" would be a better name for the win32 function and I think, that such a function is pretty uncommon. The LCL needs a "Enable a Menu Item" function. The implementation depends on the interface, so it should be an interface function.

To avoid misunderstandings:
I know, that the overhead is little, and making the function win32 compatible is easy and that we have to change/remove/rename it anyway. But every function added to the interface needs to be supported by all interfaces. We don't add win32api functions, just because they are easy to implement.
The win32 function is not exactly what the LCL needs and it is not commonly used, so these are enough reasons to ask, if we really need it.

Just say, that this function is or can be used by some nice components, and I'm the first to change it.

What about Delphi components using one of both? Does this mean, they will work only on one intf?

Mattias

Hi,

Specification of Enable/CheckMenuItem needs to be more specific. Due to win32api obscurities it needs to be changed: note that only hndMenu changed:

hndMenu: specifies _parent_ of menuitem to change
uIDEnableItem: Integer - menu item to check/uncheck bChecked: Boolean - new state of the menu item

Mattias, please fix the gtk to fit the new specification.

Micha.

We want the most commonly used winapi functions. If you think, that this function is commonly used, then ok, let's emulate it. I doubt it.

IMO the win32api function is too win32 specific. I think, nearly all other interfaces will have the ability to enable a menu item directly and don't have an "Index". So, adding this function to the interface means overhead for all interfaces, except the win32. While a direct function means overhead only for the win32 intf.

Mattias

(1) No. (2) It can't be, there is no GetParentMenu(handle) call or something like that.

Regards,

Micha.

I should have read before asking :)

Your original message:

Ehm, now I understand your question. The GTK winapi implementation of CheckMenuItem is wrong. It uses hndMenu as the item to check and ignores uIDEnableItem. But it should use hndMenu as menu and uIDEnableItem as "command or index" to the Item.

I think I missed it, I'll

I don't see it as a hack. All menu functions require a flag, telling how to interpret the uID parameter. For win32 it is MF_BYCOMMAND and MF_BYINDEX. I don't see why introducing another interpretation would be a hack.

TMenuItem's have a MenuIndex right? So why don't we pass that around? Remove the ugly Command, and use an index for positioning. Then it's easy in gtk and win32.

OK, if we drop the command, the current declaration of both CheckMenuItem and EnableMenuItem get moved out of the winapi unit into some other interface unit. Since they are not win32API compatible (I already made tham compatible, but hey, what the heck)
And if we do this, we pass a TMenuItem and nothing else (like Mattias proposed)

We cerainly dont want a half implemented api look alike

Marc

At 19:03 22-11-2003, Mattias Gaertner wrote:

I don't know what it is with mail today, I recieved this message around 2100.

I only encounterd this with Eudora when there is a MSOE client in between :)

[snip]

That's a point.

And to avoid name collisions.

That's what I had in maind aswell.

Yep

We don't add win32api functions, just because they are easy to implement.

No ? :-)

They would work on all interfaces, however if for example the Delhpicomponent used MF_BYCOMMAND, it will use some overhead. Something the native LCL components wouldn't.

The more I think about it, the more I feel for a separate unit like winapi for "direct" interface functions. (and thus use
LCL(?)EnableMenuItem(TMenuITem, Boolean)

Marc

"Easy" in the sense of "not very smart" ;)

in gtk:

- Get LCL component of Parent Menu Handle
- Get i-th child menu item and its handle
- enable menu item

The LCL converts the request into a win32api function call and the gtk interface converts it back. ;)

Mattias

This is correct. But we can't just go around a defining various specifications for different platforms! All platforms should implement *all* specified behaviour. Of the 3 options you propose the win32 handles 2 and is not able to implement the last. Currently, the gtk implements the last one. This is getting too differentiated.

I am completely against the double function call in the LCL: let's try it this, let's try it that way. Then it's certainly not readable anymore. The gtk will probably not implement the 'official' two flags, so we don't have winapi compatibility _anyway_.

I agree here. I also think while we're at it, investigate what specifications gtk and win32 use and strip it from there and place it in the interfacebase unit. Then:

1) easy check against winapi compatibility,
2) new platforms know how to implement, not only what.

About naming, I don't think EnableAMenuItem is a good name. IMO LCLEnableMenuItem would be better.

That's fine with me.

Micha.

We have 2 options here:
1) Implement a winapi-compatible function. In this case we should take the route suggested by my initial post. We should not add additional behaviour: then the whole point of compatibility is gone.
2) Implement a custom function. It can do whatever we want it to.

Since it's obvious ;) by now we don't want 1), we'll take route 2). We should change the function name to EnableAMenuItem, as mattias suggested. Shall I make the necessary modifications, or have you already begun, marc?

Regards,

Micha.

I don't see overhead as an issue here. There willbe always overhead. For these menufuntions we could introduce a MH_HANDLE flag (there is already a MF_INDEX and a MF_COMMAND) to tell the interface to use the handle.

I've been thinking about what way do we want.
Do we want to support projects like synedit ? Written in pascal, but not with the VCL ? Then we need the winapi.

On the other hand, why not introducing separate CheckMenuItem(TMenuITem, Boolean) and EnableMenuItem(TMenuITem, Boolean) functions.

What mechanism had you in mind ? Like the winapi, all flat function wrappers around the interface object ? Or are we going back to calling interfaceobject methods directly ?

Anyhow I've looked around on how to honour the MF_BYCOMMAND and MF_BYPOSITION function.
For now I think it is the easiest to introduce a MF_BYHANDLE, to use that by default in the LCL and if that function fails use MF_BYCOMMAND Then it would work on both GTK and Win32 with the least overhead.

Marc

??? Doesn't the win32 interface keep track of that (or can't it be quiried) ?

Marc

It is not complicated.

If functions are close, I prefer winApi compatible functions. It makes porting easier. I don't feel like introducing a load of similar_but_not_the_same functions.
We started with a load of api functions, I see no reason why we would replace them. If we want the api function, we have to implement it anyhow.

Marc

Maybe Eudora has a problem with mixing '> ' and '>'.

Ehm. Ok. That was misleading. I mean, we don't add win32api functions, just because they are easy to implement under gtk.

Good idea.
Maybe instead of lclapi.inc, it should be lclinterface.inc and lclinterfaceh.inc.

Mattias

Mattias Gaertner wrote

On Sat, 22 Nov 2003 21:37:00 +0100 Marc Weustink wrote:

[snip]

Don't know. It doesn't recognize it anymore as quote.

OK, better.

The same way as winapi.inc ?

Marc

Lazyness ;), no real need to do implement it, more important things to do, etc...

Micha.

Who will add it ?

Marc

OK, (it getting hypotetical, since I'm more for a non winapi function) if we did it this way, all 3 options would be implemented on every interface. Gtk would initialliy do the last, but do the others as well. And yes, the last option is also possible in the win32 interface (we might need te reimplement some parts, but imo nothing is impossible ;).

I am completely against the double function call in the LCL: let's try it this, let's try it that way. Then it's certainly not readable anymore.

Mwah, if you look on how it is done... it's stil readable.

The gtk will probably not implement the 'official' two flags, so we don't have winapi compatibility _anyway_.

Why wouldn't ik not ?

Ok, end of hypotethical discussion.

Are we able to use the interface base anywhere ? Wouldn't it create circles ?

1) easy check against winapi compatibility, 2) new platforms know how to implement, not only what.

I see no difference.

If we're going to do it this way, I'll revoke my changes.

Marc

Feel free to start.
I'm not always sure, what functions are win32 based.

Mattias

aye

Mattias

I think the comment at the top of the lclapi.inc and winapi.inc to be a little confusing:

(****************************************************************************** All Winapi related stuff goes here.
This file is used by both LCLIntf.pas and InterfaceBase.pp If a procedure is platform dependent then it should have the following tail:

     {$IFDEF IF_BASE_MEMBER}virtual;{$ENDIF}
   If a procedure isn't platform dependent, it is no part of

InterfaseBase and
should be surrounded by:

     {$IFNDEF IF_BASE_MEMBER}
       procedure MyProc;
     {$ENDIF}

****************

AFAIK, those ifdefs don't have anything to do with platform dependency, just so that they can be included within a class and declared as a global procedure by using the same inc file. Both files should be platform independant, no? Ie. functionality provided by interface should be the same for all platforms.

Regards,

Micha.

+ From: Mattias Gaertner
+ Sent: zondag 23 november 2003 2:05
+
+ On Sun, 23 Nov 2003 01:51:08 +0100 Marc Weustink
+ wrote:
+
+ > At 01:38 23-11-2003, Mattias Gaertner wrote:
+ > >On Sun, 23 Nov 2003 01:29:59 +0100 Marc Weustink +
+ > >wrote:
+ > >
+ > > > At 00:38 23-11-2003, Mattias Gaertner wrote:
+ > > > >On Sat, 22 Nov 2003 21:37:00 +0100 Marc Weustink
+ > > > > wrote:
+ > > >
+ > > > [snip]
+ > > > >
+ > > > > >[...]
+ > > > > > The more I think about it, the more I feel for a separate unit
+ > > > > > like winapi
+ > > > > >
+ > > > > > for "direct" interface functions. (and thus use
+ > > > > > LCL(?)EnableMenuItem(TMenuITem, Boolean)
+ > > > >
+ > > > >Good idea.
+ > > > >Maybe instead of lclapi.inc, it should be lclinterface.inc and
+ > > > >lclinterfaceh.inc.
+ > > >
+ > > > OK, better.
+ > > >
+ > > > The same way as winapi.inc ?
+ > >
+ > >aye
+ >
+ > Who will add it ?
+
+ Feel free to start.
+ I'm not always sure, what functions are win32 based.

OK, the new layout is in CVS now.

The winapi inc files have been sorted out and split up into winapi and lclintf
The interfacebase.inc is splitup in 3 parts, only interfacebase, winapi and lcl.
The moves for gtkwinapi aren't finished yet.

The functions in the winapi files should match the win32 api calls, the files in lclintf may be changed to suit us. I'll adapt the apiwizz tool to support these changes.

ATM, only code has been shuffeled between files, nothing has changed. One of these days CheckMenuItem and EnableMenuItem will change to LCLCheckMenuItem(TMenuitem) and LCLEnableMenuItem(TMenuitem)

Marc

Marc Weustink wrote

ATM, only code has been shuffeled between files, nothing has changed. One of these days CheckMenuItem and EnableMenuItem will change to LCLCheckMenuItem(TMenuitem) and LCLEnableMenuItem(TMenuitem)

Now it does: Lcl{Enable,Check}MenuItem implemented. Tested to be correctly functioning on win32.

Regards,

Micha.

No,
It means that they will become part of the interfaceobject and that they need a per widgetset implementation. (platform is maybe the confusing term)

Marc

Right.

, no? Ie. functionality provided by interface should be the same for all platforms.

Yes.
With a few exceptions (e.g. clipboard). The interface is the same on all platforms, but the functionality for the user differs.

Mattias

OK, implemented the gtk part. I also removed the check/enable boolena to avoid inconsistencies (The item itself knows if it is checked/enabled :) and I introduced the lclintf includes in win32

Marc