Forum > Ported from Delphi/Kylix

Solved: Porting efg2 Snowflake Curve Drawer

(1/6) > >>

Boleeman:
Had a go at porting a Delphi efg2 lab Koch Snowflake Curve Drawer.
This was an old Delphi sample program I got off WebArchive

Had a couple of errors with TRect and so included Uses Windows; which fixed that problem.

Also came up with an error at

ASSERT(GetDeviceCaps(Printer.Handle, LOGPIXELSX) =
               GetDeviceCaps(Printer.handle, LOGPIXELSY)

and replaced with:

        ASSERT(GetDeviceCaps(printer.XDPI, LOGPIXELSX) =
               GetDeviceCaps(printer.YDPI, LOGPIXELSY),
               'Printer pixels are not square');

Now the code compiles but I just get a black image. What could be the possible problem?

I am not sure if I used printer.XDPI and printer.YDPI properly? I read a couple of threads which suggested to use printer.XDPI and printer.YDPI instead of Printer.Handle

The program uses a TImage named ImageVonKoch but I can't see the code where the lines are drawn to this TImage.

Thanks in advance.

Thaddy:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---ASSERT(GetDeviceCaps(Printer.Handle, LOGPIXELSX) =               GetDeviceCaps(Printer.handle, LOGPIXELSY));Missing close ) in the code?

Boleeman:
Thanks Thaddy but I

Still get a problem with Printer.handle not being recognized?


Compile Project, Target: lib\i386-win32\KochCurve.exe: Exit code 1, Errors: 2
ScreenKochCurve.pas(160,43) Error: identifier idents no member "Handle"
ScreenKochCurve.pas(161,42) Error: identifier idents no member "handle"



 I read a couple of threads which suggested to use printer.XDPI and printer.YDPI instead of Printer.Handle?

Getting late here so I will get back to the forum tomorrow (it's 12.30 am)

wp:
This is one difference between Delphi and Lazarus: In Delphi, a bitmap is initialized filled with white color, while in Lazarus it is filled with black. Since you are setting the Pen.Color to black you are drawing black on black... Either change Pen.Color to something different from black, or fill the bitmap immediately after creating:


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---  PROCEDURE TFormVonKoch.DrawVonKoch;    VAR      Bitmap:  TBitmap;      Curve :  TVonKochCurve;  BEGIN    Bitmap := TBitmap.Create;    TRY      Bitmap.Width  := ImageVonKoch.Width;      Bitmap.Height := ImageVonKoch.Height;      Bitmap.PixelFormat := pf24bit;      Bitmap.Canvas.Pen.Color := clBlack;      Bitmap.Canvas.Pen.Width := 1;       Bitmap.canvas.Brush.Color := clSilver;      Bitmap.canvas.FillRect(0, 0, Bitmap.Width, Bitmap.Height);       Curve := TvonKochCurve.Create(Bitmap.Canvas, Bitmap.Canvas.ClipRect);    [...]
The Assert code referring to printer pixels is not correct. As Thaddy noted, you do need the Printer.Handle - but not in every Widgetset the printer has a Handle... Since you are on Windows you could add unit OSPrinters to uses, and cast the Printer to TWinPrinter: Assert(GetDeviceCaps(TWinPrinter(Printer).Handle), LOGPIXELS...). Or much butter to do it in the Lazarus way: Query the x resolution from the XDPI property of the printer, likewise with the y resolution, and compare them directly:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---        Assert(printer.XDPI = printer.YDPI, 'Printer pixels are not square');
General comment on the code:
I see that your uses clause contains both Windows and LCLIntf/LCLType. This could lead to conflicts because LCLIntf and LCLType are the "same" (well: almost...) as the Windows unit but are valid for all platforms. Simply remove the Windows unit, as well as the Messages unit (the cross-platform counterpart is LMessages). However, after removal of Windows your code will not compile any more since the TRect type is no longer declared - you must add unit Types to used to fix this.

wp:
Two more comments:
Your form comes up in the exciting style of Windows 95. If you want a modern look, like other current applications, you should check the box "Use manifest resource" in the "Project options" > "Application". And since people today have high-resolution monitors you should also check "Use LCL scaling (Hi-DPI)" and pick one of the "on" settings in the "DPI awareness" combobox on the same options page.

The other comment refers to the pixelated MS Sans Serif font which was nice at Windows 95 times but looks terribly out-dated today. Open the form in the Object Inspector, go to the Font property, set Name to "default" and "Size" to 0 - these settings make the form select the default font provided by the operating system, and this is propagated to all controls which have ParentFont = true.

Navigation

[0] Message Index

[#] Next page

Go to full version