when i compile in Lazarus the Reportdesigner with activated RangeCheck it gives a lot of runtimeerror with rangeerrors.

The definition is TFPReportColor  = type UInt32;

Loading and saving in JSON is done by

function ReadInteger(AName: String; ADefault: Integer): Integer; override;
function WriteInteger(AName: String; ADefault: Integer): Integer; override;

internally of write and read there is a cast from d.AsInt64 to integer.

This means you have at reading a AsInt64 -> Integer -> UInt32. Actual i have a value of  2147483648 ($‭80000000‬) wich make a rangecheckerror :-)

Should the definition for TFPReportColor not better TFPColor ( I KNOW THE DIFFENCES) or QWord with the according routines. Because UInt32 is not a JSON dataformat. Integer seems to be to small, so QWord fits this better. TFPColor is more FPC-Compatible (with the overhead of the needed conversions).

I am wrong ?

Andreas

Andreas Frieß wrote

when i compile in Lazarus the Reportdesigner with activated RangeCheck it gives a lot of runtimeerror with rangeerrors.

For explanation what i mean in my previous post, UInt32 is not an integer or JSON compatible size (and actual rangecheck unsafe).

ANdreas

----------------------

in systemh.inc

   maxLongint  = $7fffffff;

in objectpas.pp
    const
       MaxInt  = MaxLongint;
    type
       Integer  = longint;

in fpreport.pp

   TFPReportColor  = type UInt32;

in systemh.inc

   Cardinal = LongWord;
...
   UInt32  = Cardinal;

in fpreport.pp

const
  { The format is always RRGGBB (Red, Green, Blue) - no alpha channel }   clNone          = TFPReportColor($80000000);  // a special condition: $80 00 00 00

......
    AWriter.WriteInteger('FontColor', Font.Color); .....
    Font.Color := AReader.ReadInteger('FontColor', Font.Color); ......

in fpReportStreamer.pp

function TFPReportJSONStreamer.ReadInteger(AName: String; ADefault:
Integer): Integer;
var
   d: TJSONData;
begin
   d := FindChild(AName) as TJSONData;
   if d = nil then
     Result := ADefault
   else
   begin
     if d.JSONType = jtNumber then
       Result := d.AsInt64
     else
       Result := ADefault;
   end;
end;

Andreas Frieß wrote

The definition is TFPReportColor  = type UInt32;

That was designed and defined to handle AARRGGBB values of $FFFFFFFF (max 256 for each color channel and alpha), and that fits perfectly in a UInt32 data type.

Should the definition for TFPReportColor not better TFPColor

I can't remember from memory. Is TFPColor the one where each color channel is a Word size (ie: $FFFF)? When I wrote fpReport, that color range was note designed for and I've never seen in used in the real-world either.

Because UInt32 is not a JSON dataformat.

Well, then I'll say that FPC's JSON needs to be extended to support UInt32, as it is a perfectly valid Object Pascal data type.

Regards,
Graeme

How should FPC's JSON support something, that is not supported by JSON?

Mattias

The problem is not in JSON.

Native Javascript supports 2^52 (or so) integer values, so every UInt32 value should fit if written properly.

FPC's JSON supports Int64 and even QWord in FPC, so a UInt32 is definitely supported.

If the colors (a UInt32) is currently written as Longint (signed 32-bit) then of course a range check will follow, and this needs to be fixed.

The easiest solution is simply to read/write it as Int64.

Michael.

Another possible Problem with the definition

TFPColor (fpc)  record with word TColor (lazarus) -$7FFFFFFF-1..$7FFFFFFF TFPReportColor (fpreport) UInt32

So you cannot use in Lazarus the 'well known' TColors. With TColor it is also Delphi compatible.

If the defines are Lazarus compatible. It works for both systems. I can make a patch if needed. But the teams have to IMHO to decide the best way :-)

Andreas

Using TColor is not an option, it is windows specific and depeds on Graphics.

Michael.

Depending on the Information of the list here i have created some patches and an Bug-Report https://bugs.freepascal.org/view.php?id=33217

The heats of my changes is a more typesafe conversion and to use QWord for the JSON. So nothing is broken and it rangechecksafe now.

----- a small snippet ----

function QWordToReportColor(AQWord: QWord):TFPReportColor;
begin
   Result := TFPReportColor(AQWord and $FFFFFFFF);
end;

------------
The second, i foung a not created Font, if you are not using Parent-Fonts. Also fixed.

Thx to all who have some things more clear to me AND why.

Andreas

Checked, and applied your patch. Many thanks. The font issue is also something we seem to have missed :/

Michael.