David Heffernan

Lars understands that, I think, and wonders why the compiler doesn't take the same view and issue a warning.

That's not right. In order to evaluate expressions the debugger needs to execute code in the target process. Which may lead to allocations. It's a defect that the IDE / debugger leak such objects, but they can't do their job if they can't execute code and perform allocations in the target process.

This is a known bug in the IDE / debugger. Nothing you can do about it. Evaluating certain expressions, often involving strings, seems to be what triggers it.

This is why you should make a repro. Worth bearing that in mind for the future.

Encryption is agnostic of framework. I don't see how you could have a VCL only encryption library. You don't need design time components.

Component vendor is wrong.

Timers are for GUIs. MsgWaitForMultipleObjects is one sound way to implement a message pump on a thread that needs to do tasks periodically.

No you won't. There are plenty of timer free solutions I would expect. Very hard to give advice without context. And very hard to explain why messages are missing with only a partial extract of code. Anyway, good luck.

A complete repro is probably necessary here. A timer seems needless. Just keep track of the time when you last flushed and do it again once a second has elapsed.

You reap what you sow. Don't create multiple variables with the same name.

Don't think that's true. That's the point of the broadcast message. The shell updates its environment and uses that when creating new processes.

Did you do any debugging? Did you check that the registry was modified as intended? Reference back to https://docs.microsoft.com/en-gb/windows/win32/procthread/environment-variables

You code runs the risk of hanging when it broadcasts. But the basic concept is correct albeit poorly implemented. Have you done any debugging?

The answer in that link appears factually misleading at best, probably downright incorrect.

Provide a minimal complete reproduction.

This approach is what you take when you hate your users. They can't tell whether or not your program is stuck in a non terminating loop, and the OS asks if you want to terminate the program. So only do this if you want to make your users suffer.

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.