David Heffernan

Don't change libraries and hope. The library you use is known to work well. There's a defect in your code. Work out what it is. Trial and error never works out. Provide a minimal yet complete program ideally a console app. Then you can hope for some help.

Why would that be odd? That's pretty much a canonical use of try finally.

Jokes aside, any user that feels that the testing could be broadened can write some tests and submit a PR.

Tested 42 and Lorem ipsum, that seems pretty complete to me. 😉

No. It's in HKCU.

OK, just looked tlat the documentation and it explains it all. You have to delete the sub keys. And you won't get an error in your code because the function returns a boolean indicating success or failure. You didn't check this. Let me gently suggest that rather than tearing hair out, the documentation may help!

Don't you need to empty the key before you delete it?

Is the key empty?

Delphi is no easier than Java to learn. Delphi on mobile hasn't had the greatest track record. For instance at the moment there is no 64 bit Android compiler, thus locking delphi out of the app store. Yes there are temporary workarounds but it is not a great situation. Embarcadero are struggling to keep pace with developments on the platforms that they attempt to support. Quality has historically been a huge problem for Delphi. Both in their various compilers and related tooling, and their library code. They have a track record of releasing products and libraries that are full of bugs, and then spending many releases trying to fix them. The VCL remains a brilliant piece of work and for native Windows UI development it still excels. If I were you I'd widen the search. You say that you don't have time to learn a more difficult language. And that you want to start a business on the side. To be honest, those two statements don't sound very compatible. Making a business work takes a huge investment of time. Being a successful programmer demands mastery of tools and language. And that takes time. There are no shortcuts.

Dude, before my time. Also, how we miss Rob Kennedy from the Delphi world.

But they have a much wider scope. Not a problem if your units have only one class. But with many classes it can be an issue.

Nested methods are one of the biggest things stopping me porting my code to C++.

No, it's using arctan2 rather than arctan. Just read every single other implementation on that page. As far as both sumsin and sumcos being very close to 0, I would still advise not using a tolerance. All you can achieve by that is giving a less inaccurate answer than is possible to reach. If you want to do better, use one of the algorithms used for dealing with roundoff when calculating sums, for instance Kahan summation.

Actually the comparison against eps is wrong and should be removed. Call arctan2 unconditionally. Also the divide by cnt is utterly wasteful. Bogus comparisons against small numbers drive me mad.

The const param reference counting bug that keeps on giving. https://stackoverflow.com/a/31028671/505088 https://stackoverflow.com/a/7640979/505088 https://stackoverflow.com/q/4509015/505088 QC report 90482 and presumably many others. Of course, Emba killed QC. Thanks so much for that. Can I be arsed to re-enter all the unsolved reports that were killed when QC was killed? No I cannot.

Not so much humour as a comment about the arrogance of imagining that the big company can just decide to buy the small company. Perhaps the small company is happy to be independent.

Perhaps they could buy Greenland as well

No. Because there is no DllMain and so nothing is initialized. And then there are the lack of relocations. What's wrong with Delphi programmers. Read the standard output already!

Nope, that doesn't work. You can't expect to load an exe file with LoadLibrary. Also, even if you could, don't go exporting string across a module boundary. I'm astounded at all the posting here for a trivial problem with a standard solution.

The most reliable way to avoid the legion of bugs with this feature

Regarding a fix, this is only one of a number of problems with scope resolution in the language. Same issue arises when you use units, where more recently imported symbols hide those from units imported earlier. Same for local variables and methods. Same for local variables and global symbols. Anywhere where you refer to a symbol and there are multiple matches then the compiler chooses the most recent. In princple the resolution is simple. Introduce a new compiler warning whenever the compiler uses this most recent principle.

Debugging was never the issue. That was just annoying. Refactoring was never the issue either. That also is annoying but one of many broken aspects of the refactoring. The issue is the silent bugs that arise when you add a field to a type and that one hides local variables. This has been discussed hundreds of times. Try some more websearch. Then, stop using with.

Don't you just declare the property as TStrings? Use its Text property when you want a string representation including line feeds.

I am defending a very important, and very well respected, member of the Delphi community. That's all.

In defence of Mathias his madExcept library is superb and very actively maintained. And his response to your comments in the thread seem reasonable. Why expect him to work on freeware? Anything he does is a bonus. It looks like your frustration is getting the better of you.