Der schöne Günther

"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... 😒

https://quality.embarcadero.com/browse/RSP-23466 reports that OmniThreadLibrary is also affected. Can somebody confirm that?

Still doesn't help you for something like this: procedure p(x,y: Byte); begin if (y = 0) then raise EArgumentOutOfRangeException.Create( NameOf(y) + ' must not be zero'); (...) end;

I'm doing kiosk software that runs 24/7 and has to be able to cope with a sudden power loss. To get around the problem of corrupted local files, I usually Create a windows file handle with the flags FILE_FLAG_WRITE_THROUGH for a file like "config.ini.new" Pass that handle to a THandleStream, and save my content by SaveToStream(..) or whatever Call FlushFileBuffers(..) on that handle Close the windows file handle Atomically move "config.ini.new" to "config.ini" "Atomically move file" just boils down to procedure moveFileAtomic(const fromPath, toPath: String); const flags = MOVEFILE_REPLACE_EXISTING or MOVEFILE_WRITE_THROUGH; begin Win32Check( WinApi.Windows.MoveFileEx( PChar(fromPath), PChar(toPath), flags ) ); end; So far, everything was fine. Now I thought I was being smart and skipped step 1-4 by just using System.IoUtils.TFile.WriteAllText(filePath, fileContent). At one client with a power loss, that file ended up on disk, but just contained nullbytes. The WriteAllText method from Delphis library boils down to calling CreateFile(..) with FILE_ATTRIBUTE_NORMAL So basically what I guess must have happened: The file was not yet written do disk, and MoveFileEx moved something that wasn't even there yet. I cannot reproduce this by normally running software and not yanking the power cord out. My question is: What exactly was the cause? Was I missing FlushFileBuffers(HANDLE), was is that the original must have been created with FILE_FLAG_WRITE_THROUGH as well?

"Currency" is money. Do you mean money or plain numbers?

I don't have my RAD Studio in English, so the translation might be off: Project options -> Delphi Compiler -> Hints and Warnings -> Not supported language Features You can set this from "True" to "Error" so the compilation will stop.

Are you sure F8 is the right hotkey? I think in your case, it should be Shift+F8 (run until return). Also, TStringList is from Delphis default RTL. Be sure to have "With Debug DCU files" checked in your project or you cannot have breakpoints in there.

Nothing against nested methods (altough I never use them), but what you show is way over the top. Let's put all these things in a single class.

It's beyond me why, if it's never getting fixed, why they can't at least add a compiler warning. We don't even have warnings for the most obvious mistakes like using an uninitialized return value or this. I don't understand why.

Do you mean just using the pen for drawing some stuff (maybe including text recognition)? Or are we talking about more elaborate things like tilt angle of the pen or using built-in graphical brushes like pencils? If the first is enough for you, these features have been in Windows since XP. If you don't mind Kraut language, some fine gentleman put together a very decent demo that does text recognition in a VCL application => https://www.delphipraxis.net/192146-stift-eingabe-zum-schreiben-auf-tablet.html By the way: Of course the Microsoft Surface might be the most famous device, but it's not limited to Surface devices. A lot of devices have pen support, some also with tilt support.

This is something I really miss when using other IDEs, I really fell in love with "every 10nth line number".