Uwe Raabe

Seems it is time to get to know the reason now.

The simplest way is to create static fields for the query and set the DisplayFormat of the Hour field to hh:nn (Note: mm gives the month).

You may even try to contact sales online: https://www.embarcadero.com/company/contact-sales If you've got that decline by email, check if it contains some phrase that you should contact sales instead. OK, they might try to sell you an update, new license or something similar, but you don't need that to get your registration counter bumped.

No, unfortunately that won't help. Although you remove the license from that PC, you won't get a registration bump with that. The key for getting a bump without active subscription lies here: While the technical support is the right place with an active subscription, you should contact your local Embarcadero Sales representative for a bump when your subscription ran out.

If it were a bug and it is not filed in QP it most likely will never be fixed. To file it as a bug report in QP (with hope it going to be fixed) one needs a detailed description and steps to reproduce.

I guess, the spooky part is the in some files...

I don't know, because up to now I've never let my subscription run out.

It is just a reminder to renew your subscription, just in case you missed to do that.

One possible scenario: Product Management schedules RSP-38842 for 12.3 Product Owner assigns the task to implement that to some developer Developer implements it in an interface breaking way Developer team realizes that the change cannot be done in 12.3 and postpone merging the change Unfortunately they forgot to notify the Product Owner to adjust the fix version

It looks like a mistake when writing these release notes. A new event would be an interface breaking change and thus cannot (should not) be implemented in a point release. Most probably this will make it into Delphi 13.

Can you point to the comment you are referring to?

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.