Lars Fosdal

When you look in the form designer, are the OK and Cancel buttons correctly parented? I.e. are they on the expected place in the form hierarchy?

It is VERY hard. Especially when you can't persuade the debugger to break ONLY in the thread(s) that you want to debug.

I am about to embark on learning IBM Cloud Pak for Integration - which is a low code solution for API development. The low code bit is a buzzword, because you are looking at learning and applying a lot of ESQL to achieve what you want. It feels like early VB / Delphi in a way - only with a worse UI.

In that case, I would have created a worker thread (or threads) that have a private RIO, work in, work out queues, and a default heartbeat ping loop method that is called when the work in queue is empty .

I am curious - why would you not create it when you need it? I checked our code, and we typically create on demand per thread.

When it fails, does it always fail (on that machine)? Is there any red thread such as OS version and patch level, display driver, etc between the machines that fail?

As long as the RIO is used only by one thread at a time, that would work fine.

In that simple case, it is not more clear.

I moved it to the more appropriate group..

Give me written articles over video any time! If the article is shit, you can spot it in seconds, but I've wasted too many hours watching videos while hoping there will be something useful in there.

Technical Debt and Legacy - an endless source of work 🙂

Not that it has any bearing on this problem, but I keep my shared image lists in a data module

Valid point. Some of my exception handlers deal with specific exception(s), as well as shared handling code. Hence I write it the way that I do for clarity. An exception is already costly AF - so code efficiency is not a big deal.

Those are obsolete pages, but they do show the 2007 installers if you pick The current download page is: https://my.embarcadero.com/#downloadsPage and mine shows RAD Studio 2007 ISO as well as Delphi 7 Professional

With EurekaLog, it is possible to capture and log EVERY exception before it is handled, so why bother with interfaces? We use inheritance, mostly to classify exceptions for a sub-domain. Exception - ParsingException - InvalidCSV - InvalidEmptyField try Parse; except on E:Excepetion do if E is ParsingException then LogSomethingInformative else raise. end;

Any problem can be expanded into something insurmountable if one so likes. But, if you apply the KISS and Pareto rules- you can at least start out with a less complicated scenario.

Pretty much. Add corner cases as they happen.

Just from the top of my head... 3 + -3 3 + - 3 3 +- 3 - 3 + 3 -3+3 -3 + +3 How tolerant do you want the parser to be? I wrote a parser that did math on arrays in a stock price technical analysis tool back in the 90's. I built the parser so that it generated an expression tree, so the same calculation could be done rapidly on a number of data points. I could multiply a stock price with a currency price and subtract the adjusted value from the Oslo exchange with the same listed stock on NYSE. Good fun!

It depends on the parser. Sometimes it can be just "can this string be recognized as a valid representation of a value?", other times you could parse a generated artifact, or a predefined artifact.

It would be natural that the test cases also contain negative tests - i.e. stuff that is supposed to fail. Only testing happy path = recipe for disaster. You want to know that if you get garbage in, at least your code can recognize that it is garbage, report the problem, and move on.

Dictionary and anonymous methods. Link the method to the keyword. Look up via the keyword and execute the code.

The X is for eXcellent 🙂 Edit: On the serious side, we chose DUnitX because the use of attributes allowed us to do more testing with less code. Also, it is super easy to integrate with Continua CI. Many of the tests are there to verify that we f.x. have working FromString/ToString methods for all our enumerated types, validation of algorithms, and such - but a lot of the tests are actually closer to integration tests than to unit tests. F.x. there are a large number of tests that do CRUD testing for our database objects. We should add more tests, to be honest - but so much to do, so little time, so the Pareto rule, rules.

All our apps, including our services, are self-upgrading/restarting. It has worked flawlessly for years. We set up the relaunch to be executed in the finalize statement of our upgrader unit, so we know the application has actually exited when we relaunch.

I just installed FMXLinux 1.68 which required a restart. No lingering BDS.exes for me. I keep Process Hacker running most of the time, and I can't recall seeing multiple BDS processes after a GetIt install.

How about testing for 'FOR SELECT' first? Then again - what if there are two spaces between FOR and SELECT ? If you want to "trim" all spaces, you still have to avoid doing so inside string literals. Parsing can be complicated. I hope you don't plan to expose this to users, because they could wreak havoc on your database.