[lazarus] Enable/CheckMenuItem

[Marc Weustink]

At 21:45 22-11-2003, Micha Nelissen wrote:
>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.

OK, (it getting hypotetical, since I'm more for a non winapi function)
if we did it this way, all 3 options would be implemented on every 
interface. Gtk would initialliy do the last, but do the others as well. And 
yes, the last option is also possible in the win32 interface (we might need 
te reimplement some parts, but imo nothing is impossible ;).

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

Mwah, if you look on how it is done... it's stil readable.

>The gtk will probably not implement the 'official' two flags, so we don't 
>have winapi compatibility _anyway_.

Why wouldn't ik not ?

Ok, end of hypotethical discussion.

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

Are we able to use the interface base anywhere ? Wouldn't it create circles ?

>1) easy check against winapi compatibility,
>2) new platforms know how to implement, not only what.

I see no difference.

If we're going to do it this way, I'll revoke my changes.

Marc