[lazarus] Enable/CheckMenuItem

[Marc Weustink]

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.

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

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

[snip]

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

That's a point.

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

And to avoid name collisions.

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

That's what I had in maind aswell.

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

Yep

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

No ? :-)

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

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