Uwe Raabe

That exactly describes a blocking behavior. As long as the specification says blocking and you want non-blocking, you better change the specification first before doing anything with the code.

AFAIK, that won't work with Inserts via SQL (at least I never did it that way). The reason may be, that an INSERT query will never retrieve any fields like a SELECT query. There simply are no fields you can get the ID from. The usual way you have something like SELECT * FROM MYTABLE which retrieves all fields including the ID field. For adding a new record you just call Append or Insert, set the field values as needed and call Post. If everything is set up correctly, the new ID should then be available in the PERSON_ID field.

Can you explain what you see as the benefits of the aware mode while accepting to not being able to read the tiny forms?

It can be found on the status line:

The breakpoints are store in the DSK file - either project or the project group one, depending what you have opened.

Yes.

I actually gave it a try on 10.4, but I have difficulties to distinguish the tiny icons then. I admit to have a higher scale than only 125%

This is standard for D11 and it works quite well when you use the scaled designer, too. Unfortunately that will change your DFM files often in an unwanted way. As long as you are the only one working with these files it might be acceptable, but in mixed environments it is often not really usable in the moment. Seems that Embarcadero itself doesn't make use of the scaled designer: All PixelsPerInch in the form resources of CoreIDE280.bpl are 96 DPI.

Can you please elaborate on that?

DPI unaware mode doesn't hinder you to write DPI aware applications with Delphi, which works pretty well meanwhile. It is just that the IDE runs at 96 dpi internally scaled by Windows.

A version of MMX suitable for D7 can be found at the download page after clicking Previous versions. Delphi 7 is supported up to V13.

Can you check if you have some file named Forms.pas or Forms.dcu anywhere in your search paths?

Is that with all units of that project or only with some of them? Anyway, the implementation is quite similar to my command line tool UsesCleaner. If you are curious and the problem persists with that you can debug it yourself without giving away your project sources.

I copied the uses clause as well as the group/sort-order from your post into a fresh VCL forms unit and this is what I get: uses System.Classes, System.SysUtils, Vcl.Forms, Vcl.Graphics, Vcl.Menus, Vcl.StdCtrls, Vcl.ExtCtrls, Vcl.Controls, Vcl.Dialogs, Winapi.Windows;

Sorry, but I cannot reproduce here. Can you give an example for such a uses clause, please? To be honest, I doubt that there is some wrong with the code. The algorithm tries to find a unit (like Sysutils or Forms) in the search path. If not found, it tries each entry in the Unit Scope Names. That doesn't rule out any uncommon uses clause, so I would like to see an example showing that problem.

ExtractFileName(ExeName)

Don't forget to tell them that they shall notify you when someday their hardware changes.

TThread.ProcessorCount seems what you are looking for: /// <summary> /// The number of processor cores on which this application is running. This will include virtual /// "Hyper-threading" cores on many modern Intel CPUs. It is ultimately based on what the underlying /// operating system reports. /// </summary> class property ProcessorCount: Integer read FProcessorCount;

Probably because the threads compete for a free core? If there are more threads than cores, they are not executed one after the other on a core, but are interrupted to give other threads a chance to run. It is even possible that a thread runs on several cores until it finishes. Given the timing for the 1 thread case, the theoretical minimum for 12 thread should be less than 100 ms, which is far away from the actual numbers.

The size can be retrieved from System.TMonitor.CacheLineSize.

Not when you add MidasLib to the uses clause.

There is already TimeOf for that.

Probably because Now contains the date and the time, while EncodeTime uses an implicit date of 0. You may have better results with MyTime := Time; // uses the time part only BackUpStart := dm.SettingBACKUPHOUR.AsDateTime; // which is 20:30 BackUpEnd := BackUpStart + EncodeTime(0,30,0,0); // which is 21:00

Since Delphi 11 the Form Designer adapts to the theme set in the Appearance settings if the corresponding option is enabled.

The variable is defined in the base configuration, so it is safe to use it in the inherited ones, but fails when used inside the base configuration itself. A possible solution is to normalize the project file with Project Magician, which places the variable in front of any others in the base configuration.