Leaderboard

Of course not. However parallel programming is not a piece of cake. There are so many ways you can shoot yourself in the foot and then blame the library.

Make a small testcase to demo the bug so others can confirm it or point to error in code.

Please allow me to disagree. I have made non-trivial use of System.Threading in PyScripter (used by thousands of users) without any problems. The main issue I know of with the library is RSP-11267. You can see a fix in that report, but even without the fix you can work around the issue by using a different mechanism for signalling task to stop As for Parallel.For I have not used it extensively, but you can see some code of mine in this StackOverflow question that I think is now used in a commercial product. An issue with thread creation by Parallel.For (RSP-21177) has been fixed in Rio. Advantages of System.Threading: By far the easiest way to use tasks (as opposed to threads) in your delphi application Nice interface using anonymous methods Avoids third-party dependencies It provides usage statistics that can be used for diagnostic purposes Nowadays, it provides good performance out of the box, but you can still fine-tune the way it works if you are prepared to dig-in It uses state-of-the-art synchronization techniques @Primož Gabrijelčič can correct me on this, but by reading his book "Delphi High Performance", I think, that depending on the type of use, is competitive if not faster than his own OmniThreadLibrary The Parallel library, like many other new features of Delphi (e.g. Generics) got a bad reputation, due to the many bugs in the early days. Unfortunately. trust is easy to lose and very hard to rebuild. But the library does deserves some love from Embarcadero (fixing remaining issues) and Delphi users.

Yes, but it does not use Exit(True) any more but requires an additional line: Result := True; Exit; And of course the begin / end block to allow for two statements. This would be my preferred solution: function HasCheckedSubItems(AMenuItem: TMenuItem): Boolean; var I: integer; begin for I := 0 to AMenuItem.Count - 1 do if AMenuItem.Items[I].Checked then Exit(True); Exit(False); end; (But I rarely use any Delphi version that supports Exit() with a return value.)

Basically it is like declaring the class interface where it is needed and move the implementation to another unit. Very similar to interfaces - just another approach.

A while ago, after my post on Known IDE Packages in Delphi I wrote a the KnownIdePackagesManager tool which lists those packages, allows to disable and enable some of them and also set the package description for those packages that don’t have a meaningful description. Today, I updated the tool to support Delphi 10.3 Rio. https://blog.dummzeuch.de/knownidepackagesmanager-tool/