Recent
Recent Posts
It feels like no one here cares about FPC.
I've also found a couple of bugs and I'm worried that some of them will be ignored if they are released together.
No,trunk is published in this year and only trunk supports 64-bit PE format files.There is no timetable.I know the trunk version of fpc can make PE-64 files,so how long do the fpc publishs 3.3 stable version so I can use PE-64 format files as a UEFI bootable files?
But FPC already supports 64-Bit PE files for nearly twenty years already? After all it had been the first open source compiler to support Win64.
make all OS_TARGET=linux CPU_TARGET=mipsel BINUTILSPREFIX=mipsel-linux-gnu- FPMAKEOPT="-T <cores>" -j <cores>
make install OS_TARGET=linux CPU_TARGET=mipsel INSTALL_PREFIX=/where/you/want/your/compilerBut, the problem I was facing was that in order to use a COM interface, my class definition had to inherit from TInterfacedObject, but I also had to inherit from another class. To prevent that I used Corba.
Using for in syntax for an array seems unnecessary and probably should not have been implemented. It makes sense for a set where items are in no particular order . I wonder why they added this bloated feature? Is it for delphi compatibility or something?
But I believe this:QuoteContrary to ordinary constants, a value can be assigned to them at run-time. This is an old concept from Turbo Pascal, which has been replaced with support for initialized variables.
should only be possible in TurboPascal mode. In modes Fpc and ObjFpc should not be supported. Or this:QuoteSupport for assigning values to typed constants is controlled by the {$J} directive: it can be switched off, but is on by default (for Turbo Pascal compatibility). Initialized variables are always allowed.
in Fpc and ObjFpc modes it should be disabled by default.
So yes, it is high time Free Pascal and Lazaru supports aarch64 targets on Windows - the only (and ironically, biggest) platform where they lack this support.
I would be in favor if Windows was available for ARM64 and supported various devices such as Raspberry Pi, Organe Pi, etc. I mean the real one, not a substitute in the form of Windows IoT (earlier RT and even earlier CE). But these are more of a dream. Porting WinAPI from AMD64/EM64T to ARM64 is years of work (if it is technically possible).
In some situations, like the example below, the error message points to $define instead of actual line where the error has happened:
But it doesn't make any sense. If the Width property is in pixels, or in pixels relative to current UHD resolution, then hardcoding a Wdith/Height inside is a bad thing, right ? Cause these numbers would be really hardcoded to the UHD resolution and wouldn't change.LCLScaling will make them change since the form stores the PixelsPerInch at which the form was designed. Knowing this all dimensions are adjusted automatically when the resolution changes.
In the Lazarus options ("Environment" > "Form Editor") there is a checkbox "Enforce DPI Scaling at designtime". This should be checked.The thing is in CodeTyphon the Form Designer has navigation bars on the form, so I can make the form larger while its window remains smaller. When the application starts, the form is created at its full size.Yes, that's the form editor. You can do this in Lazarus, too, when you install the DockedFormEditor package. I don't use it, so I can't tell which effect it has on LCLScaling.
