[lazarus] Enable/CheckMenuItem

[Mattias Gaertner]

On Sat, 22 Nov 2003 18:18:36 +0100  Marc Weustink <marc at dommelstein.net>
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

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


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

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


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

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.


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

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


Mattias