Leaderboard

You should be able to do that, as each Exception object in the chain is preserved as-is and would carry its own CallStack, which JCL can populate as each Exception is raised. https://blog.eurekalog.com/2010/05/new-exception-class-in-delphi-2009-and_05.html Not really, because you are still raising twice. Whether you raise and then re-raise 1 object, or raise 2 objects, is up to you.

I (relunctantly) agree with ChatGPT on this one - you should not modify the original exception, but instead you should raise a new exception that captures the original exception into the new exception's InnerException property. However, the way that ChatGPT demonstrates this is wrong: Firstly, SysUtils.Exception does not have a public SetInnerException() method. ChatGPT suggests defining a new class, but then doesn't use that class. And that class is just trying to replicate a feature that already exists natively in SysUtils.Exception. Second, ChatGPT's approach does not release ownership of the original Exception, so the try..except will still try to free it when the except block exits, leaving the new Exception holding a dangling InnerException pointer to a now-dead Exception. The correct way to capture an InnerException is to use the SysUtils.Exception.RaiseOuterException() method, eg: try sqhpartyroles.sql := fsqlhandle.buildsql; sqhpartyroles.executesql; except Exception.RaiseOuterException(Exception.CreateFmt('error from sql %s', [sqhpartyroles.sql])); end; (I don't like this syntax, but it is what it is...) Higher up the call chain, you can then catch the new Exception and traverse its InnerException chain if you want to report/log all of the individual error messages, eg procedure MyForm.Application1Exception(Sender: TObject; E: Exception); begin repeat // use E as needed, then... E := E.InnerException; until E = nil; end;

Because the language spec - pardon, the compiler - says so. Constraints on generics are part of the declaration.

I really think it's more a question of lack of expertise, limited resources, and priorities. I think they would if they could but since they can't communicate that to the customer they instead come up with excuses that comes across as if they don't care.

"It's not the bottleneck, therefore, I don't care" is the reason why Embarcadero does not care to implement anything that is reasonably optimized.

Could you elaborate on what you found impossible to do with .pkg files? FWIW we use Packages as a comfortable way to build these. And if all else fails, you could make the .pkg run a shell script so there's almost no limit on what you can do.

We use DropDMG (https://c-command.com/dropdmg/). It's inexpensive and very convenient. It has multiple templates for different installers and creates a signed DMG package by just dropping the app on its window.

... and write all sources in YAML format, no ?

My version of the Mineseeper game, posted today at the RAD Programmer Coding Challenge #1, was fun to develop and at the same time learn how to work with skia4delphi, really a diamond in the rough that has been added to delphi. Thank you. If you can, visit the project's github and give it a star if you like it. https://github.com/abritolda1972/MinesweeperFMX

Continuing with the "funny" compiler "errors": 1. Optional semicolon (for global and nested proc declarations only!!!) if you have any of these specifiers (platform, deprecated, assembler, register, stdcall... etc): But semicolon is required if this is a const/var/type/method 2. Crazy mixing of these specifiers (you can mix all these specifiers as you want): 3. Crazy mixing of "platform" specifier for global variable declaration: I suppose there are much more similar "bugs", I see it on 11.3 and 12.3, and believe emba will never fix it, their favorite answer - don't do like this! 😄

I hate reinventing the wheel..... Wanted to do something a little different. After a few iterations this is where I ended up... https://github.com/jimmckeeth/MineSweeperHex I want to dress up the UI some more. Double-click to restart (after game over).

That is not a bug, but a feature of the Pascal language. More formally, inside a block ('begin..end' or 'repeat..until'), a semicolon is a statement separator, not a statement terminator, unlike with other languages. The last statement in a block is never terminated by a semicolon. If you write a semicolon, then the last statement will be an "empty" statement. Another quirk of Pascal requires a semicolon to be omitted when an 'if..else' is inside of a 'case of..else' to avoid ambiguity over which statement the 'else' belongs to: https://stackoverflow.com/questions/7574603/why-do-single-statement-blocks-require-not-using-semi-colons

I usually place a client aligned TPanel onto every TForm and TFrame with all borders removed and ParentBackground set to False. That way all forms and frames are drawn with the current styles panel color, which is usually the same as the form color.