Alexander Elagin

I usually use a simple class with a counter and two methods, like BeginWait and EndWait. The first one increments the counter and sets the cursor to crHourglass if the counter was 0, the second one decrements the counter if it is positive and reverts the cursor back to crDefault when the counter is 0. Of course, with the obligatory try..finally to make sure that each BeginWait has a matching EndWait and with critical sections if multithreaded.

I'd use the DevExpress controls anyway, nothing can beat them in the VCL design. Just a single dxLayoutControl with manually added custom groups and maybe a few cxPageControls placed into it if necessary (and ActionList+dxBarManager+cxStatusBar etc for the toolbars) can easily handle this layout, and the latest versions are significally faster than the initial releases of the said control. The design phase may look tedious but once everything is ready and locked where necessary there will be no problems in maintaining/extending/modifying the UI.

I think it has to be XE 10.3.2.1 and then XE 10.3.2.2. Makes as much sense as the current silly naming convention.

Devart has a Secure Bridge suite of components to protect a database connection (https://www.devart.com/sbridge/). I have not used it but maybe you could have a look if it suits your needs. I'd rather replace a direct client-server solution with a 3-tier one, thus totally isolating the database from network access.

The IDE functionality in 10.3 is fundamentally broken. Don't try to find logic in its look or behaviour...

OK, understood. I think that these shortcuts, Ctrl-Alt-C (copy entity) and Ctrl-Alt-V (paste entity) were initailly selected as logical extensions to common Ctrl-C and Ctrl-V, but the IDE has better use for them.

There is another valuable shortcut (Ctrl-Alt-V) which is used by IDE to open the Event log window, but MMX re-registers it for some action I always have to reconfigure back.

No, VMware workstation stores all files for one virtual machine (vmx, vmxf, vmdk, nvram) in a single directory which you can freely move around. The next time you open this machine it will simply ask if it was copied or moved (to update uuid if necessary).

... unless the string is a ShortString, which was the default and only string type in Turbo Pascal days ;-). Yes, I am that old. Then having predefined constants for the empty string and pointer made sense. Since the introduction of AnsiString/UnicodeString, all these constants became useless and are kept in the RTL due to sentimental reasons, I think. And the IsNullOrEmpty is a C#ism which does not belong to the Pascal world and makes no sense at all.

It looks like a dumb copy of the .net String.IsNullOrEmpty method public static bool IsNullOrEmpty (string value); which, according to the Microsoft docs, " Indicates whether the specified string is null or an empty string (""). " What it has to do with the Delphi string implementation and why was it implemented? I do not know.

BTW, strictly speaking, the EmptyStr in SysUtils is not a constant. It is declared as an initialized variable. I think this goes back to either Borland Pascal 6 or Delphi 1 when empty string and nil pointer were two different things, and the compiler/linker had to allocate precious memory to store each constant. If one had many empty string references in the code, using a predefined one saved some valuable space. Today, of course, this is totally irrelevant, that's why the documentation says "Empty string and null string pointer. These constants (sic!) are provided for backwards compatibility only."

Are they really fixed? I picked a random item (RSP-24261) from the List of customer-reported issues fixed in 10.3.2 . It still has status "Open" and resolution "Unresolved". If this release were properly planned I'd expect at least to have QC entries match the real state of the things before curious customers like me start investigating.

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;

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 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.