[fpc-devel] proposal for palette-related graph unit interface changes

[Tomas Hajny]

On Wed, September 15, 2010 18:03, Nikolay Nikolov wrote:
>   On 09/15/2010 06:27 PM, Tomas Hajny wrote:
>> On Wed, September 15, 2010 16:39, Nikolay Nikolov wrote:
>>>    Currently, the following palette-related things from the fpc graph
>>> unit aren't TP7 compatible:
>>>
>>> MaxColors (constant)
>>> PaletteType (record)
>>>
>>> procedure SetAllPalette(const Palette: PaletteType);
>>> procedure GetPalette(var Palette: PaletteType);
>>> function GetPaletteSize: smallint;
>>> procedure GetDefaultPalette(var Palette: PaletteType);
>>   .
>>   .
>>> so the main difference is that fpc's PaletteType represents a VGA 256
>>> to
>>> RGB colour palette, while TP7's represents EGA's 16->64 palette. My
>>> proposal is to rename:
>>>
>>> MaxColor ->  RGBPaletteMaxColor
>>> PaletteType ->  RGBPaletteType
>>> SetAllPalette ->  SetAllRGBPalette
>>> GetPalette ->  GetAllRGBPalette
>>> GetDefaultPalette ->  GetDefaultRGBPalette
>>> GetPaletteSize ->  GetRGBPaletteSize (this one might be unnecessary -
>>> will have to check if GetPaletteSize already returns the same values as
>>> TP7; we might still introduce GetRGBPaletteSize for consistency with
>>> the
>>> other RGBPalette procedures/functions, though)
>>   .
>>   .
>>
>> Regardless of outcomes of discussion whether some change would be
>> appropriate at all or not, I believe that it may be better not to rename
>> the existing procedures and functions using the PaletteType but rather
>> provide overloaded versions of those calls.
> This could work for some of the functions, but not all of them. The
> problematic one is SetAllPalette, which is defined in TP7 as:
>
> procedure SetAllPalette(var Palette);
>
> which is, unfortunately, very evil, because it won't catch the error at
> compile time if you pass the wrong type :(
>
> But it might not be necessary to introduce it exactly like that. Using a
> typed variable will probably work with 99.9% of the TP7 code?

I'd assume so; even if not, simple typecast in the TP7 code would be
sufficient to make it to work which should be an acceptable limitation (no
need to change the logic or so).

Note that even having one version specifying the RGB type and the other
defined the same way as in TP7 seems to compile with FPC and should be
still compatible to both existing TP7 and FPC code, because FPC always
requires to specify the type currently (and having the type specified
should always result in selection of the typed version) whereas the TP7
code would be just as dangerous as with real TP7.

Tomas