[lazarus] Enable/CheckMenuItem

[Mattias Gaertner]

On Sat, 22 Nov 2003 17:18:31 +0100  Marc Weustink <marc at dommelstein.net>
wrote:

> At 17:08 22-11-2003, Mattias Gaertner wrote:
> >On Sat, 22 Nov 2003 12:41:30 +0100  Marc Weustink <marc at dommelstein.net>
> >wrote:
> >
> > > At 09:04 22-11-2003, Micha Nelissen wrote:
> > > >Marc Weustink wrote:
> > > >
> > > >>At 22:23 21-11-2003, Micha wrote:
> > > >>
> > > >>>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
> > > >>
> > > >>??? Doesn't the win32 interface keep track of that (or can't it be
> > > >quiried) ?
> > > >
> > > >(1) No. (2) It can't be, there is no GetParentMenu(handle) call or
> > > >something like that.
> > >
> > > I should have read before asking :)
> > >
> > > Your original message:
> > > >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
> > >
> > >
> > > 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.
> >
> >Why that complicated?
> 
> It is not 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.
> 
> 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.

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