Alexander Elagin

All this once again raises a question about a LTS verison of Delphi. Let those who need yearly new bells and whistles have their yearly releases, and the others who need to have a solid stable version have it with all the necessary patches.

A redundant begin/end block around a single Continue, maybe? It just increases the number of lines and clutters the view, IMHO. if Utc.IsZero then Continue else begin _UtcValid := Utc; ...

Delphi 10.1 DevExpress VCL 20.1.5 win32 / Debug configuration Blank application: 2 200 576 bytes Blank application with a single TdxPDFViewer: 15 368 704 bytes With an autogenerated toolbar: 21 126 656 bytes.

I think that not much has changed in the structured storage implementation in the last two decades. If the library you are using works (and you have the sources) it will work until MS drops the OLE storage (or CFB, as they call it now) support. Anyway, it is all based on a simple set of COM interfaces (IStorage) and it would be easy to use them directly or write a simple wrapper if needed. Documentation for IStorage compound file implementation

It is more stable in the configurations it is being used now. If nothing in the OS has broken thus far and no updates expected which can break something (as it regularily happens with "supported" OSes) I'd say XP machines will run until they break physically. Again, those computers are mostly not exposed to internet and are therefore not vulnerable to net exploits.

I was going to suggest this solution myself but then I thought it was too obvious 😉 and the code in System.Threading (which I quoted) was written by somebody more clever than me...

But using GetTickCount64 in fact is a must for their code in the Threading unit which internally uses the milliseconds counter. As you know, the counter overflows every 49 or so days and some threads in your server application just hang waiting until the condition TThread.GetTickCount > FLastSuspendTick.Value + TThreadPool.SuspendInterval is fulfilled... I got hit by this myself. Of course, it mostly matters for the applications that run 24/7, but anyway using the 64 bit counter is a wise decision.

It is probably a semantic question. A ternary operator, by definition, is any operator that takes three arguments. The conditional operator ?: is just one of the set of such possible operators. It is easy to imagine, say, operator AAAND which takes three logical arguments and produces TRUE only if all of them are true, but the usefullness of such operator is not high. As for the textual representation of a ternary operator, it is a problem. While a binary operator naturally is placed between its arguments, it is worse in case of the ?: operator which in fact is written as two lexems divided by one of arguments. Were it written as a = ?: b, c, d it would be more strict. Maybe. Or maybe not.

In fact, Delphi supports named parameters, but only for automation (OLE/COM) objects. Like this (from http://www.blong.com/articles/automation in delphi/automation.htm): //An Automation method call, using two named parameters MSWord.Selection.InsertDateTime( DateTimeFormat := 'dddd, dd MMMM yyyy', InsertAsField := False); MSWord.Selection.TypeParagraph;

Have been using paid VMware Workstation since its version 5, no problems thus far. Easy to carry VM (on a eSATA or USB3.1 external SSD drive) between different computers, no problems with USB devices in the guest OS (I stick with W7 Pro as the guest OS). Graphics is a bit slower in the guest compared to the host, otherwise no speed differences.

FMX might be good for mobile OSes, but not for heavy desktop applications. If one needs a Linux version of an existing VCL application with years of manpower already invested in its development, then going the FMX way means the total rewrite of the UI in the best case, or even some internal logic if the application does not have some ideal architecture (trust me, this is the most common case). Meanwhile, Lazarus clearly demonstrates that it is easy to make a crossplatform (Windows/Linux) desktop application with a single VCL-like codebase, and even convert an existing Delphi VCL project if it does not use complex third-party components. Alas, DevExpress suite is too complex and too Windows-rooted... I understand that Embarcadero decided to make its cross-platform framework from scratch thinking primarily about the mobile OSes. The Linux support arrived many version later, without any desktop support and only in the very expensive edition - as if they decided that Linux is something used on servers only. This is obviously not the case, but I think they have already lost the race to Lazarus. If only Embarcadero had decided to sublicense CrossVCL instead of FMXLinux... but they chose the wrong path.

I remember compiling a (then) large FoxPro program with a text windows interface on PC XT. It even would not link at all - the linker crashed after a half of an hour - unless I replaced the linker with another (probably Watcom but I do not remember the detail) which could finally produce a working executable in just 40 minutes of heavy work. Those were the days...

Mainly for the historical reasons. Turbo Pascal back in 1980's implemented a set of mathematical functions as a part of its standard (default) library which was implicitly used by any project (and still is in Delphi). This set included among others sin, cos, arctan but not tan, because it is simply sinus divided by cosinus. Now, decades later, Delphi significally extended the function list, which are now implemented in a separate unit System.Math. But the original functions are still available by default without using this module.

In Delphi, trigonometric functions (along with other mathematic routines) are implemented in the module (unit) System.Math. Do not forget to add this unit manually to the uses section of your module where you use them: uses System.SysUtils, (...other units), System.Math;

In fact, this was a pretty common trick when implementing ccustom lists before generics.