[lazarus] Enable/CheckMenuItem

[Marc Weustink]

At 17:34 22-11-2003, Mattias Gaertner wrote:
>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.

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