M.Nelissen at student.tue.nl
Sat Nov 22 15:35:43 EST 2003
Marc Weustink wrote:
> At 20:01 22-11-2003, Micha Nelissen wrote:
>> Marc Weustink wrote:
>>> 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.
>> We have 2 options here:
>> 1) Implement a winapi-compatible function. In this case we should take
>> the route suggested by my initial post. We should not add additional
>> behaviour: then the whole point of compatibility is gone.
> You don't break compatibility by adding extra functionality as long as
> you also support the original functionality.
> What functionality the LCL uses doesn't matter, that won't break anything.
This is correct. But we can't just go around a defining various
specifications for different platforms! All platforms should implement
*all* specified behaviour. Of the 3 options you propose the win32
handles 2 and is not able to implement the last. Currently, the gtk
implements the last one. This is getting too differentiated.
I am completely against the double function call in the LCL: let's try
it this, let's try it that way. Then it's certainly not readable
anymore. The gtk will probably not implement the 'official' two flags,
so we don't have winapi compatibility _anyway_.
> At this moment it might look like only needed for menus, but I think it
> implies more. By just adding another function we aren't finished.
> Today I looked at the winapi unit and a noticed that it is already
> polluted with non winapi functions. This is misleading. IMO the winapi
> unit should only contain winapi compatible functions. All others,
> including the new enablemenuitem should go to another (lclapi ?) unit.
I agree here. I also think while we're at it, investigate what
specifications gtk and win32 use and strip it from there and place it in
the interfacebase unit. Then:
1) easy check against winapi compatibility,
2) new platforms know how to implement, not only what.
> About naming, I don't think EnableAMenuItem is a good name. IMO
> LCLEnableMenuItem would be better.
That's fine with me.
More information about the Lazarus