Uwe Raabe

Even that can be handled with initially wiring FormFirstShow with OnShow and inside wiring the regular FormShow. Not that I am actually promoting this approach, but I am neither a friend of these Run-Once-Booleans cluttering a class declaration.

There are several SQLiteWrapper units supporting different libraries and linkage: FireDAC.Phys.SQLiteWrapperStat.pas, FireDAC.Phys.SQLiteWrapper.FDEStat.pas and FireDAC.Phys.SQLiteWrapper.SEEStat.pas, while dynamic linking is implemented in FireDAC.Phys.SQLiteWrapper.pas as default. There is also a way to select the required one: Drop a TFDPhysSQLiteDriverLink onto your main form or data module and set its EngineLinkage property to your needs. This even allows to switch linkage at runtime.

But the OnShow event is called before the position and size of the form are set. Thus OnResize is called after OnShow.

Can you be more explicit, what these some things may be?

Well, no official announcement from MS, if you are looking for something like this. The source is the shear lack of proper support in Windows itself. One can talk and write a lot or not - in the end it is facts that count.

Windows 10 doesn't support MDI child forms with Windows 10 style. Microsoft deprecated MDI since about XP and proper support for newer features will probably never be done for MDI windows. See also: MDI window title in Windows 10

Even then this can be wrapped in a separate procedure (or whatever it is) with a non-colliding name published at a suitable location. When multiple occurrences have to be dealt with, the effort is merely the same with the benefit of better readability. type TWinBitmap = Winapi.Windows.TBitmap; procedure SysAbort; inline; begin System.SysUtils.Abort; end;

Indeed, it has. It is just not supported, as well as a couple of other scenarios. It is supposed to work when the assignment is isolated on that line. I have added a feature request. While the official way would be to mail to support@mmx-delphi.de, this place is also OK. It has the advantage that it is public and others can join the discussion.

Indeed. Actually having multiple developers building the same project can be the trickier part when it comes to shared resources. Of course it may need some investment first - that is money as well as time - to get it working properly.

Usually MMX avoids to duplicate functionality already available in the IDE. In most of the cases where it does, it is probably the IDE implementing a similar feature recently (f.i. Extract method). If you feel MMX needs too much time to parse the unit after changes not made by itself, you might try to reduce the Delay times in the General -> Synchronization options of MMX. The defaults were made for hardware standards now pretty much outdated.

Obviously you can't have both.

The application needs a manifest with a compatibility entry for Windows 10.

I wonder when anyone comes up with a request for threadconst.

... unless you allow that with a compiler directive: Writeable typed constants

Tools > Options > IDE > File Association

CmonLib Initializing provides a way to register a procedure to be called during Application.Initialize. This allows to make adjustments before (f.i. in the dpr file or some units), which would be near to impossible if the initialize code would execute in the units initialization section.

IIRC, he said that internally there is a road map. They use to have private talks to selected users about their needs, which may influence their road map. He also mentioned that there is no official road map due to legal concerns.

Indeed, my statement covered only the simple case, where a batch file was executed by doubl-clicking it from the explorer. The actual details are ever so often a bit more sophisticated. F.i. you can wrap commands in SETLOCAL and ENDLOCAL to make temporary changes: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setlocal

As long as it is a native Windows control, we are limited by its internal functionality. Currently it doesn't support that: Edit Control Styles

AFAIK, the change to the PATH variable lasts until the batch file ends (unless executed by a call). If you need to call different Delphi versions inside the same batch file, you might save the original value and restore it before calling the next rsvars.bat.

Well, in that case...

This usually happens when you either run the IDE under a different user account or registry branch.

Usually it is sufficient to call the rsvars.bat of the required version: call "c:\Program Files (x86)\Embarcadero\Studio\23.0\bin\rsvars.bat"

Well, TParallelArray has been introduced in 12.2, so it won't be available in 12.1. One just cannot use something from 12.2, that did not exist in 12.1. This must not necessarily be used by your own code, but it can by some 3rd party code.

Technically you also get half of the bottom frame with that.