Fr0sT.Brutal

I don't see how it could help... if you want to extend any exception, incl 3rd party, they won't implement the interface. If you want to extend your own classes, why not inherit them from extended base class. Btw, you can wrap all exceptions thus extending ALL of them: (pseudocode) except on E: raise EExtended.Create(InnerException := E, AddInfo := ...) end Exception class even has the pointer to Inner exc already but I've never used it

Turn detailed logs on or use sniffer to realize at what stage the issue happens.

HtmlViewer supports CSS but of course only that is linked with HTML

You're right, I solve this problem by adding test data to assert message. Yep, I think so too. Writing tests I sometimes find design/code/API flaws and fix them before a method is used widely in app

Depends on implementation. IBX likely will as the snippet I posted shows

Generally speaking, only DB engine can reliably say what the query type is.

IMHO this picture is not applicable here. If you learn how to unit test Calc, you're ready for testing anything. Just write tests and adopt some tricks on the way. You can examine some unit-tested project for inspiration. I personally came to these conclusions: - Use as little assert functions as possible. You don't really need Assert.IsAssigned, Assert.StartsWith etc - Assert.IsTrue/False or even Assert.AreEqual covers all these cases. In fact, I tend to use only AreEqual, AreNotEqual, WillRaise. Even WillNotRaise is not so necessary - maybe just for test counter, though it could be replaced with DoSmth; Assert.IsTrue(True). Reason is that Delphi lambdas add too much noise. With all that you depend less from testing framework and could easily switch it or conditionally plug another one (f.ex., DUnitX for Delphi and fptest for FPC with a single codebase). - I don't bother testing obvious things like Assert.IsTrue(Assigned(TSmth.Create)) - I don't separate each check into its own method. If a test fails, no matter if others are OK or not - you have to fix it anyway. So I test all cases of a method Foo instead of Test_Foo_InvalidArgs, Test_Foo_NoArgs, etc. - Sometimes I write tests first and then implement a method, this helps to understand what I want as a result. - I try to test as much edge cases as possible - they are frequent causes of app failures and crashes. - I avoid placing test data in attributes. Just don't like the idea. If I have to repeat the same thing with different args, I just extract it to a method and run from test body. External data sets (files with test data and expected results) are nice as well as they separate code from data so you can modify test cases without touching the code. These are just my personal habits.

IDK. Check it yourself 😉 this is kinda trick so it's hard to predict when it will work and when won't

Isn't Query.Active doing what is needed? I can't check now myself - busy with other projects

I'm pretty sure there are many implementations, one of them is in EhLib. Search for "custom panel + combobox", take a look at main component packs (check awesome Delphi list in my signature). The component shouldn't be too complicated

Just a small change: unit DMSomething; uses ..., NoDPIDataModule; // add this type TDataModule = NoDPIDataModule.TDataModule; // and this TDMSomething = class(TDataModule) ...

function TIBDataSet.PSGetCommandType: TPSCommandType; begin if not Prepared then Prepare; case SQLType of SQLSelect, SQLSelectForUpdate : Result := ctSelect; SQLInsert : Result := ctInsert; SQLUpdate : Result := ctUpdate; SQLDelete : Result := ctDelete; SQLDDL, SQLSetGenerator : Result := ctDDL; SQLExecProcedure : Result := ctStoredProc; else Result := ctUnknown; end; end;

I must say a word of defense here. Probably my cases were simpler but I successfully do this "step back" from time to time.

CnPack has plugin for stripping out excess props on DFM save

Your words should go into God's ears (handmade translation of a native saying)

Nice! I was always using RMB>Debug>Set next statement

Hmm, https://www.ffmpeg.org/index.html#news seems pretty fresh and it's used by youtube-dl for decoding YT videos so it should work.

Where applicable, I handle this case with, umm, case. if CharInSet(ch, ['Ň'..'Ř']) => case ch of 'Ň'..'Ř': .. end but of course this only works with constants. While I sometimes miss ability to use predefined sets in case, it never been too big trouble for me. All formats I had to parse were like "ASCII for markup, Unicode for content" so I just didn't need to examine Unicode but if I had to, Unicode categories defined in System.Character could be real helpers

While this could be the fastest option, I'd recommend using char literals instead of ASCII codes: Word(#13) or Ord(#13) or even better Ord(CR)

When writing some new class, I try to design structure first, write stub methods and then implement them one by one. Alas, implementation details frequently dictate structure change so I have to redesign it. I'm not a fan of TDD either when creating from the ground, I prefer to have something more or less ready to use. Of course, as soon as the state is compilable (I try to keep it such), I periodically compile. Then I test - run, create tests etc. When modifying code, I write and run tests ||-ly, sometimes it helps to understand what I want from a method.

Seems like they're loaded by relative path.

I have no idea about legality and pretty sure you considered that but doesn't playback via ffdshow solve the problem?

JS is pretty cool here for const [str, obj] of sl if (str == aStringArg) return obj; I partially agree with you. I love for-in but the fact it hides current index makes it non-applicable in pretty much cases.

Or make unit tests open source and ask community to join them. This would help at least keeping lib in stable state.

Awesome! 😄