[lazarus] Enable/CheckMenuItem

Marc Weustink marc at dommelstein.net
Sat Nov 22 13:03:04 EST 2003


At 18:56 22-11-2003, Micha Nelissen wrote:
>Marc Weustink wrote:
>
>>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.
>
>Nooo...please, that's an ugly hack imho.

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






More information about the Lazarus mailing list