Uwe Raabe

I'm sorry, but I cannot understand your problem in the first place. Can you create a small example to allow us to reproduce?

I urge to create a bug report with detailed steps to reproduce. It should be verified that the patch is the real cause and that it doesn't happen without it. That allows others to confirm this or give hints what configuration is necessary to make it happen or not. The changes incorporated in this patch are probably pretty small, so the cause should be easy to find.

AFAIK, they require an active subscription (at least that is mentioned in GetIt as of 10.4.2) , which is not available for the Community Edition. The fact that they were available in 10.3 was probably an oversight.

As far as I understand, the dongle is for the system that does the signing, not the one checking the signed exe. The problem I see is that this completely counterfeits the idea of virtualization when the dongle (or HSM) is hardware bound. I can move around my build server and agents, which are all realized as VM. If my build machine breaks, I can easily set up a new one and continue. In case of a dongle I may be able to move it too, as long as it did survive the fire, flood, earth quake or bomb attack that destroyed the old machine. It creates a new hardware dependency and a single point of failure.

I wonder how the option is going to work. Do we all have to send our dongles to Amazon or Microsoft so they can plug them into their servers? There must be a system that allows to deploy the certificate to these services in some way. As they mention a "such as" for AWS or Azure, there should exist something like an API or guide to implement this for other cloud services, too.

My signing process is part of the build process running at the build server being a VM on an ESXi machine. While I have no problem to connect the security device to the physical machine, I still need to see if and how it can be accessed from the build server VM.

Can you revert the update to see if it can actually be the real cause?

What types are dsetAddUser and tbAddUser and how are they related? Where do you specify the table name the insertion is supposed to go?

Well, that can obviously be simplified to b := 1;

There is! Via the IDE menu select Tools - Manage Platforms, then switch to Additional Options, uncheck Help and click on Apply.

You can achieve the desired result with TTimeSpan: diff := TTimeSpan.Subtract(ET, ST).TotalHours;

That may indeed be a problem with Delphi and/or the TreeView control. MMX suffers from the same symptom.

As said, the error is not the search itself, but the refactoring part of the search menu, which barfs on some source code. As the underlying parser will be replaced by an LSP based one in the future. If you have no need for the refactoring at all, you can just disable the package in the Delphi registry: Known IDE Packages, $(BDS)\bin\refactoride280.bpl, edit the value and insert two underscores at the beginning. No guarantee, that the IDE will not get somewhat unstable by this. In that case revert the change.

AFAIK (and I'm pretty sure of that), the full path is just for display and was never supposed to be edited. If you want to change it you need to remove that package and add the other one.

And you are really sure that you were able to do so before you installed GExperts?

Next time please try if just closing and reopening the project is sufficient.

There are types of applications that benefit a lot from this concept, where I can hardly imagine how it would be without it. Just to name a few I heavily work with: Delphi IDE, RAD Server and FinalBuilder.

Delphi 11 supports Monterey, but Delphi 10.4 does not. So upgrading will be a solution. https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Supported_Target_Platforms https://docwiki.embarcadero.com/RADStudio/Sydney/en/Supported_Target_Platforms

Enterprise

No, the Delphi version I tested the fresh KSVC installation had never had installed them before.

Probably the TDBEdit has its AutoSize set.

I still cannot reproduce with Build 0937 and the latest KSVC from GetIt.

Yes, the package is the same as it has been with previously installed Delphi version. I will try again with a fresh KSVC installation from GetIt.

If I understand it correctly this is a FastReport issue caused by a new version. So if you opt to update FastReport you have to compile your appication with the new dcp files and deploy it together with the new bpl files. Nevertheless, you should be able to keep it compatible by using the old FastReport dcp files when compiling the project.

Same here, no error.