Alexander Elagin

How about this (in the dpr): Application.ShowMainForm := False; // <-- insert this line Application.Run;

...that returns us to the ultimate question: why FmxLinux and not CrossVCL? 😉 Let FMX live in the mobile world and VCL rule the desktop. Lazarus team managed to make LCL (which is a VCL replica) work in many desktop environments, CrossVCL already exists, so I still wonder why FmxLinux was preferred by EMB. Only because it was advertised as the next big cross-platform thing which was meant to replace VCL when it first came out? CLX, another cross-platform Delphi library which was meant to replace VCL, is long forgotten, yet VCL lives.

As for the IDE quality and usability, nothing can beat Delphi 3 and Delphi 7. From the newer versions I'd pick XE (the last Win32-only version, pretty stable and fast) and 10.1 (Win32 + Win64, more or less stable and good-looking). I tried 10.2 and 10.3 but stayed at 10.1. My opinion on 10.3 is simple - it is a skinned snail-paced bug-ridden abomination. Were it not for the Linux compiler returned to the classic memory management, I'd never again touch it.

I felt the same when AnyDAC, now FireDAC, was sold to EMB (or whatever was its name back then) when I just paid its renewal for another year. Needless to say I never got my money back nor got access to FireDAC which I avoid since then because of such attitude. Luckily, DevArt (UniDAC) offered a great alternative. I just hope that FmxLinux and CrossVCL will remain property of KSDev.

No, it is for both Linux and MacOS: https://www.crossvcl.com/

I'd prefer CrossVCL, but anyway this is a good step.

Function localeconv() returns a structure containing the locale information, including the currency symbol. http://man7.org/linux/man-pages/man3/localeconv.3.html

DevExpress has just released a new version of the VCL controls suite (19.1). A replay of the Julian Bucknall's presentation is available now.

I stumbled upon AES problems a month ago (using a two decades old code which worked ok) when it suddenly appeared that SizeOf(LongWord)=8 on Linux. I solved my problem by explicitly replacing LongWord -> UInt32, PLongWord -> PUInt32, array -> packed array and probably AnsiString -> RawByteString and something like this (I don't have the code at hand). At least these changes in the code helped to produce equal results in both Win32 and Linux64 versions. I do not know the internals of the Eidos implementation but probably the required changes are also minimal.

From the same Atanas Popov's article: "Our objective is to make staying on Update Subscription a “no brainer.” " Currently staying on Update Subscription is a nightmare. While with any other software product it is usually a matter of pressing a "Renew" link on a web page and entering card detail, the last time I tried to renew the Delphi subscription it was a ten days long process with a busy email exchange and even a phone call (!). Not to mention that the renewal price is not published anywhere and the renewal itself involves asking for a quote. Looks like Emb is not interested in Update Subscription customers, too. If only I was wise enough to avoid using custom attributes, generics and anon functions in the code, I'd happily move my 2M+ lines core codebase to Lazarus, but alas currently this is not possible. But lesson learnt.

Add inline directive to the property accessors and check if it helps. In your example adding this directive completely eliminates function calls in the generated code. function GetX: Integer; inline; procedure SetX(AValue: Integer); inline; function GetY: Integer; inline; procedure SetY(AValue: Integer); inline;

I just spent two days debugging an innocently looking piece of code which works correctly when compliled with Delphi Win32, Delphi Win64, FPC Win64, FPC Linux64... but not with Delphi Linux64. The reason was that the Delphi Linux64 compiler for some obscure reason has SizeOf(LongWord)=8... Well, I had to look at the Delphi 10.3.1 help file, which has the following sentence: "Platform-independent integer types always have the same size, regardless of what platform you use. Platform-independent integer types include ShortInt, SmallInt, LongInt, Integer, Int64, Byte, Word, LongWord, Cardinal, and UInt64." Damn. Then I scrolled the help ten lines up and... "The platform-dependent integer types are transformed to fit the bit size of the current compiler platform. The platform-dependent integer types are NativeInt, NativeUInt, LongInt, and LongWord". Confusing, isn't it? The FPC at least is consistent.

Remember this hot topic re bringing Linux support to the Pro edition like any other platform already there? There is a famous RSP-17195 with a huge number of votes. Well, as one could expect, this issue has been closed with a popular resolution: Won't Fix. So much for the popular demand...

I wonder if Sternas Stefanos (CodeTyphon, you know) considered this option. As far as I can see, his CT bundle uses FPC trunk.

NewPascal tried to be such a fork but also died because (I guess) Maciej could not do all by himself and there was nobody else to work on the code. Do you think that another fork could be more successful? Yes I clearly that the FPC compiler development came to a roadblock due to aiming strange goals (I like "More OS/2 support" and "New compiler targets: Support for the i8086-win16 (16-bit Windows) target" as the future plans ) and THAT is a real problem . Otherwise we could already have a real cross-platform VCL (LCL) combined with a pretty good compiler, while now I just cannot use advanced Delphi libraries (like Grijjy) with FPC and have to use Delphi Linux compiler with its debugging nightmare and no desktop support. And I am honestly afraid that if said Linux desktop is ever implemented it may be FMX-based which means rewriting all UI instead of going the LCL way (one common VCL-compatible layer supported by different widget sets - winapi, gtk, etc).