Uwe Raabe

Delphi 12 already has a separate menu item for this unter Tools.

The current implementation of the code formatter is deprecated, probably because it relies on some dotnet code that is going to be thrown out. I expect a proper replacement for the formatter in the future.

AFAIK, the Modeling option is selected by default. So, as long as you don't deselect it...

It doesn't even get a name to search for: function TRESTRequestParameterList.AddItem: TRESTRequestParameter; begin Result := Add as TRESTRequestParameter; end;

Have you tried using the parameterless AddItem function overload and set the Name, Value and Kind in its result?

Regarding speed, the docwiki link states at the end: Depending on the requirements about the restrictions mentioned in the lines above that quote, assigning Data may be the better approach, while CopyDataSet covers a broader use case.

If the tables have the same structure it might be as simple as using two TFDTable components with their attached connections and call CopyDataSet on the target one.

You didn't mention the Delphi version, but since Delphi 11 you can use the appropriate Sort overload taking a comparer, start index and count. procedure Sort; overload; procedure Sort(const AComparer: IComparer<T>); overload; procedure Sort(const AComparer: IComparer<T>; Index, Count: Integer); overload;

Seems it already exists: RSP-42131

If Debug-DCUs is not active there will be no blue dots in the Delphi sources.

Only when you want to break or step into the Delphi units.

When I run that code in a vanilla VCL Forms Application in a ButtonClick event - nothing happens. Either commenting out the last line or inserting a Sleep(100) before makes the ShowMessage appear. The problem here is that the anon method captures the variable and not the value. Thus setting the value of TerminateProc to nil has influence of what is passed to TThread.Queue. It heavily depends on the timing of whether the Queue call comes first or the setting to nil. Seems not to be a valid solution to avoid the leak.

There are different levels of beta testers...

Another approach would be to declare a TMessage descendant that the frame (and probably also any form) subscribes to during creation and unsubscribes from on destruction. Then you can broadcast this message when the language changes. uses System.Messaging; type TLanguageMessage = class(TMessage<string>); ... procedure TMyFrame.HandleLanguageMessage(const Sender: TObject; const M: TMessage); begin var msg := M as TLanguageMessage; SwitchToLanguage(M.Value); end; ... TMyFrame.Create FLanguageMessageID := TMessageManager.DefaultManager.SubscribeToMessage(TLanguageMessage, HandleLanguageMessage); ... TMyFrame.Destroy TMessageManager.DefaultManager.Unsubscribe(TLanguageMessage, FLanguageMessageID, True); ... NotifyLanguage TMessageManager.DefaultManager.SendMessage(nil, TLanguageMessage.Create('DE'));

You mean, that I am part of the beta? That is already known in public IAW Embarcadero: TZipFile Improvements in Delphi 12

During the beta I use private forks of the public repositories to store all the changes. On release date the fork is merged into public. I don't distinguish code I may publish or not.

AFAIK, the TNT Unicode Components were acquired by TMS a couple of years ago, but they are tagged compatible up to Delphi 10.2 now: TMS Unicode Component Pack - looks like they are just abandoned.

You can always tweak the source of DUnitX.Loggers.GUI.VCL.pas to your needs. Currently the code for saving is located in FormClose. Besides extracting it to a dedicated method, it can be inserted at the beginning of RunExecute. In Contributing.md you find instructions to make your enhancements available for all.

Well, the FormatFloat implementation has the E15 hardcoded and even documented:

Well, FormatFloat acts as expected; for var I := 1 to 10 do Writeln(FormatFloat('', I/10)); for var I := 1 to 10 do Writeln(FormatFloat('', I*Power10(1, 14))); Output:

Have you tried with AxisValueFormat being empty?

At least that is how I read the license:

When you create a new test project and add one of the units for testing, the project won't compile unless all dependent units can be found. So you need to add the search paths accordingly. There is nothing wrong with having dependencies in the first place. It just makes picking only one unit from the project into another one a bit difficult. Nevertheless, it is always worth thinking about minimizing dependencies, but not only because of simpler testing. The not seems appropriate, but the term project to be tested should be changed to test project.

It depends on the actual sources. I have had projects that just needed a compile with the new version and target, while others lasted several months.

That could even be simplified to: for var btn in [Button1, Button2, Button3, Button4, button5] do btn.Enabled := not btn.Enabled;