Uwe Raabe

Yeah, I know. That's a pity...

A stable Delphi is also important to me. That's why I do my best to help Embarcadero achieve this.

There are several toolbar issues listed as fixed in 12.2.

It doesn't happen here and at least I cannot remember having this seen anytime. As usual: Can you reproduce with a vanilla IDE installation?

You can iterate the protected DataLinks property (there are several ways to access a protected property described elsewhere). For each TDataLink in this list act according to the actual class type: A TFieldDataLink gives you access to the corresponding Control, while a TGridDataLink provides the connected Grid. There are other classes inherited from TDataLink with other purposes, but that should you get started.

Make sure that the query is not Active in the designer.

Are you aware that your second example won't compile? It needs an additional var keyword between the constant declaration and the following field declaration.

IMHO, it absolutely makes no sense to issue a warning about an Unsafe typecast of <mytype to <mytype>, when neither these are different types nor any type cast is done at all (let alone one being unsafe). The most matching issue in QP is probably this one: https://quality.embarcadero.com/browse/RSP-30869. Given that it seems to be fixed, there may be a good chance that the current failure will be fixed, too.

IMHO, this warning is just bogus and it shouldn't be emitted in the first place. So the usual way would be to file a bug report to fix the compiler. Unfortunately there already exist a couple of issues about this warning and Embarcadero seems to prefer to ignore them because this warning is off by default and they see no sense in activating them. (Not that I would actually support this solution.) In case you need to keep these warnings active, you might consider wrapping all occurrences in {$WARN UNSAFE_CAST OFF} ... {$WARN UNSAFE_CAST DEFAULT}

It is basically what the IDE does to support the entries in the configurations. So, yes, that will work. Actually, it matches my proposal a few posts above.

I found the first entry of this function in Delphi 2010 and it misses the semicolon already.

Indeed there are: Set TControl.RaiseOnNonMainThreadUsage := True This will raise an EInvalidOperation when CheckNonMainThreadUsage is called for a control. This is automatically done inside CreateWnd.

Shall I read that as we made changes to the interface part? Interesting. A short test on my system showed that it was not possible to navigate to any VCL source file when the $(BIN)\source\VCL entry of the browsing path was missing. It's probably not me alone who would be interested in a reproducible test case.

After installing the patch most of the packages compiled with the unpatched version must be re-compiled to work with the patched version.

Wrong! According to N.Wirth (Pascal User Manual and Report page 149) there is an Empty Statement: