Thanks, applied.

Micha.

I think it generates correct code. At least I didn't see any strange things while executing a test program. If you use the '^' it uses a different header in the windows unit.

I also found a bug in canvas.inc.

See attached patch.

Regards,
Vincent.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gz00064.gz
Type: application/octet-stream
Size: 584 bytes
Desc: "poly.patch.gz"
Url : http://localhost/pipermail/lazarus/attachments/20031230/cc1386f3/gz00064.obj

If I put the ^ back, will fpc 1.9.x generate the correct code? In that case, I will put it back gladly. Otherwise, please make the windows unit between 1.9 and 1.0 compatible....

Micha.

Hi,

ATM I can't make lazarus with fpc 1.0.11. The reason is this:

Fpc 1.0.10 contains the folowing functions in the windows unit.

function Polygon(_para1:HDC; var _para2:POINT; _para3:longint):WINBOOL;
external 'gdi32' name 'Polygon';
function Polyline(_para1:HDC; var _para2:POINT; _para3:longint):WINBOOL;
external 'gdi32' name 'Polyline';
function PolyBezier(_para1:HDC; var _para2:POINT; _para3:DWORD):WINBOOL;
external 'gdi32' name 'PolyBezier';
About 2 weeks ago the FPC team changed these to:
function Polygon(_para1:HDC; _para2:LPPOINT; _para3:longint):WINBOOL;
external 'gdi32' name 'Polygon';
function Polyline(_para1:HDC; _para2:LPPOINT; _para3:longint):WINBOOL;
external 'gdi32' name 'Polyline';
function PolyBezier(_para1:HDC; _para2:LPPOINT; _para3:DWORD):WINBOOL;
external 'gdi32' name 'PolyBezier';

Note that the second parameter is not a var parameter anymore.

Yesterday Micha fixed a lot of range check errors, but in the process changed
Windows.Polyline(DC, LPPOINT(Points)^, NumPts)
To
Windows.Polyline(DC, LPPOINT(Points), NumPts)

The same to the Polygon function, but not the PolyBezier function. Question 1:
Should the same change be made to PolyBezier as well? Question 2:
Can the compilation be fixed for fpc 1.0.x? (By putting the '^' back or $ifdef?)

Regards,
Vincent.