Leaderboard

In the attachment you can find a high-level interface-based encapsulation of the Direct2D SVG functionality. It allows you to parse SVG files and draw them to a GDI/GDI+ DC. Requires Windows 10 with Creators Update or later. Main form code to display SVG files: { TForm1 } procedure TForm1.FormCreate(Sender: TObject); begin fSVG := GetD2DSVGHandler.NewSvg; fSVG.LoadFromFile('..\..\browser.svg'); //fSVG.FixedColor := TAlphaColorRec.Red; //fSVG.Opacity := 0.5; fSVG.GrayScale := True; end; procedure TForm1.Paint; begin inherited; fSvg.PaintTo(Canvas.Handle, TRectF.Create(ClientRect), True); end; procedure TForm1.Resize; begin inherited; Invalidate; end; Features: Scale to any size Keep aspect ratio (optionally) Control opacity Recolor to any color Draw in gray scale Samples: The above in grayscale: Svg.zip

GExperts supports even more laziness I got into programming because I am lazy, I’d rather have the computer do the boring work than doing it myself. So it’s no wonder that I always liked Delphi and GExperts because both support my laziness. Today I added yet another feature to save me a key stroke or mouse click: The “Close Exception Notification” expert. You probably have encountered those libraries that always raise the same exception class on errors, or even worse, raise the generic Exception class instead of bothering to declare their own. And if I should guess, you have probably been guilty of doing that yourself (as I definitely have). Why is that a problem, you ask? Because you can’t easily ignore these exceptions during debugging. You always get this “Debugger Exception Notification” dialog, have to read it and decide whether you want to break and look at the code or ignore the exception. Read on in the blog post.

Currently very much enjoying this feature while running unit tests with a lot of exception checking under the debugger! 👍

Just a suggestion from someone who also wrestled with supporting multiple Delphi versions in his library: Use AtomicXXX throughout the code and declare them for the older Delphi versions that did not have them yet - that way you get the best code generated by the newer compilers that know about these intrinsics rather than putting indirections for everyone in order to be backwards compatible.

You can do dynamic test creation in DUnitX by creating a TestCaseProvider https://github.com/VSoftTechnologies/DUnitX/blob/master/Examples/ProviderExample.pas https://github.com/VSoftTechnologies/DUnitX/blob/master/TestCaseProvider.md I just pushed a small change that makes it easier to create unique test case names. Note - this won't resolve the debugging one case at a time issue though, unless you modify how your TestCaseProvider somehow.

Check out how you can use Custom Managed Records to reduce the number of try..finally blocks you write. https://blog.grijjy.com/2020/08/03/automate-restorable-operations-with-custom-managed-records/

Discussion about FPC / Delphi CMR is available here: https://forum.lazarus.freepascal.org/index.php?topic=43143.0 So not compatible yet. But I guess that FPC - in {$mode Delphi} will eventually be Delphi compatible. See https://wiki.freepascal.org/management_operators as reference.

Thanks. The aim is to integrate it with https://github.com/EtheaDev/SVGIconImageList

The current implementation of CMRs is full of lost opportunities: In C++ you can prevent copy/assignment simply by removing the copy/assign operator and it will not compile if you try - in Delphi we have to use runtime exceptions, yugh... In C++ you can directly access members on a unique_ptr or shared_ptr because you can override the * and -> operator - in Delphi you have to make some property to access the wrapped object. Oh, and thank you CMRs for making my code slower which does not even use them!

FLRE is the fastest of all! One single pascal file which is good The author is a kind of genius But not as extensively tested as PCRE poorly documented not very well supported the performance gain compared to PCRE+JIT is not that big System.RegularExpressions has a nicer interface All-in-all I would stick to System.RegularExpressions at least if you add JIT.