Der schöne Günther

He told Windows not to tell RAD Studio anything about the "true" DPI. Windows should "lie", pass 96 DPI and then handle the scaling on the operating system level, instead of the application level. Windows did so when using DPI scaling with 125% or 150%, but not with a "custom" 115%.

I should have mentioned we are using the good old GnuGetText / dxGetText for localization. It seems to do some magic to swap out the method for resolving resource strings from System.pas with something else. I can only say that "It just works".

We are using this. Passing a pointer to a ResourceString instead of the (already translated) ResourceStrings allows us to show localized error messages to the user while using English messages when logging the exceptions to disk.

That sounds like your VM lacks proper drivers for hardware accleration.

Possibly related? http://blog.marcocantu.com/blog/2017-june-delphi-packages-creators-update.html

Then he probably has initialised the variable with nil or something else before entering the loop. Because otherwise, you get a compiler warning.

If you're actively exiting the loop, then everything is fine. You're probably talking about compiler warning W1037.

I can't say how you define severe. Of course there is overhead for the 2nd process, but your 1000s of entries should be well possible. I suppose this is also how professional logging solutions like Gurock SmartInspect (also available for Delphi) do this (Link)

So you need to Be able to cope with 1000s of entries per second Do not lose a single entry when the process crashes fatally Since you say it "Debug logging" and you don't need to survive a powerloss: Use a second process. This can casually flush the log entries to disk when a certain threshold is reached and has no problem with your main process crashing.

By itself, TB does not really have much to do with TA. It's just a type definition, it's full type name is TA.TB. Since it's just a type definition and no instance, you could have multiple instances of TB inside your TA instance. You can have TA.TB instances outside of a TA instance. You can have a TA instance with no TA.TB inside at all.

"It renders crap" is not a very accurate description of the problem you're having. Care to upload a screenshot? And maybe your application manifest?

See also: https://www.xkcd.com/713/

I haven't done any benchmarks and don't know how much memory usage is a concern in your case- But I would assume that Creating a new list (you already know the capacity) Adding only the needed items Let your variable/field point to the new list could be a valid option.

Personally, I like to store those things in a local variable as it makes it easier to debug, but that's probably just personal taste.

I would do it like this: procedure p(); var itemsToDelete: IEnumerable<TFoo>; begin itemsToDelete := List.Where(valueIsSmallerThan100); List.RemoveRange(itemsToDelete); end; function valueIsSmallerThan100(const item: TFoo): boolean; begin Result := (item.getValue < 100); end;

Also, maybe I'm a bit of an extremist, but I loathe default parameters. I think Delphi still has that bug where you can't serialize a TDictionary<X, Y> because RTTI looks up a parameterless constructor, but the constructor of the TDictionary actually is something like "Create(OwnsObjects: Boolean = False)" which is not the same and the constructor never gets called and you end up with an object in a zombie state. Coding guides like MISRA/AUTOSAR (M8-3-1), HIC++ (Kap. 9.1.2) or even Google agree on default parameters.

Refrain from methods with half a dozen parameters, that's just not readable anymore. https://sourcemaking.com/refactoring/smells/long-parameter-list Use a parameter object, and make the values nullable/optional. Then you don't even have overloads for your method anymore. And validation can happen in the scope of your argument object. Like this: type TMethodArgument = record action: TTaskAction; task: TTask; schedule: Nullable<TDateTime>; isQueueOnly: Boolean; hasImmediateExecution: Boolean; class function Default(): TMethodArgument; static; function getIsValid(): Boolean; end; procedure TMyClass.someMethod(const arg: TMethodArgument); begin if (not arg.isValid()) then raise EArgumentException.Create(..); // your stuff here... end;

I'm not able to find anything in that regard over at delphipraxis.net, and the only thing I can find here is

The sourcecode from FMX.Platform.Win.pas (at least in 10.0 Seattle) does it all by itself and just launches "osk.exe" which is the keyboard from your second picture. The first one ("tabtip.exe") can (and as I believe, should) be launched instead. Here is an example: https://www.delphipraxis.net/186239-win-8-bzw-10-touch-tastatur-aufrufen.html#post1312405 Here is another but (not Delphi): https://github.com/AlexeiScherbakov/osklib I see that TVirtualKeyboardWin.Create() in Fmx.Platform.Win.Pas may use hardcoded paths to "osk.exe", but there is also a global variable "VirtualKeyboardWin". I think you should be able to subclass TVirtualKeyboardWin to use "tabtip" instead. And thenm let the global variable point to an instance of your subclass.

The second one ("OSK") is a legacy keyboard while the first one ("tabtip") is the one that should be used, in my opinion. Normally, Windows will invoke the keyboard when clicking/tapping text boxes with a finger (or pen, when configured). With FMX, it's still painted internally and not a "true" windows edit field with a HWND, right? I see FMX does its own thing in TVirtualKeyboardWin.Create (FMX.Platform.Win.pas), so you can probably use the global variable "VirtualKeyboardWin" and stuff in an implemtation that does not use the hardcoded path to "osk.exe".

Always have a base class for your forms/frames. When adding a new form/frame to your project, do not inherit from TForm/TFrame, inherit from TMyForm/TMyFrame.

I believe what you do is what Embarcadero actually recommends: http://docwiki.embarcadero.com/CodeExamples/Rio/en/FMX.ScrollableForm_Sample

I haven't been doing anything with FireMonkey for a few years now, but maybe the TLabel on Android is a native component and the operating system handles the text while on iOS, it's basically a FireMonkey paintbox that does not support RTL text?

Are you certain this was for BitBtn and stuff? I have seen it with TImageList, and it's from CnWizards

Good to know, thank you both. Sad to hear nobody really believes in Delphis PPL. Our main product has a weird mix of OmniThreadLibrary and Delphis PPL, I think if we ever upgrade beyond 10.0 Seattle, then we should probably get rid of Delphis PPL as well... 😒