David Heffernan

Sometimes. It depends. Wrong.

If you can't write to HKCU then there's something wrong. It's a huge topic, and different programs will have very different content in their manifests. This is something that is documented, so if you want to learn more, that's where you start.

Are we both talking about HKCU here? Depends what you are trying to achieve.

If you needed admin to write to HKCU, then how would users save user preferences? And registry virtualisation? Well, that is only for processes without a manifest. That was only ever a crutch for migration back in 2005.

He isn't. He has tried one or the other, but never both.

Your machine won't work if users can't read and write to HKCU and can't read from HKLM. So what do you mean by this?

Just a comment. Explicitly destroying the form is objectively better. The form should not take the decision that when closed it must die. That's best done by the form's owner.

I guess this code is written assuming that you will have certain namespace aliases defined. You'll get the same error in a 32 bit app as you get in a 64 bit app. If you don't then your project settings are different in 32 and 64 bit. Perhaps you defined some of the settings in the 32 bit config rather than the base config.

Don't you need to do this for all canvas operations because it's an issue with pooled GDI objects.

LCG's are deterministic, and @Attila Kovacs showed that Delphi's LCG won't ever produce that sequence. Probability isn't really the issue here, because we have pushed this PRNG so far beyond its zone of effectiveness that we can no longer reason about it using probability.

There seems to be a lot of hating on @Mike Torrettinni here, but this is actually a reasonably subtle issue. What @Attila Kovacs has pointed out is that Delphi's 32 bit linear congruential generator (LCG) PRNG algo in Random is not capable of generating that specific sequence. This isn't so much a weakness of Delphi, rather it's just a feature of 32 bit LCG, true weaklings in the world of PRNGs. If you want to generate sequences of length more than a handful of values, then this PRNG is not the right choice.

@Mike Torrettinni now that we all know your password I suggest you change it!

Doesn't seem like nitpicking here. It seems like it actually matters whether the issue is that the compiler has generated the code, or that the debugger won't break on it. Both seem to have been called in to question. As somebody who tries to solve problems, I know that clear terminology makes it possible to clearly specify and describe the problem.

You mean that the code is not compiled and so never runs? Or that the debugger cannot break here. The fact that you seem to confuse the debugger and the compiler isn't helping.

Correct that the debugger should capture it (note it's the debugger not the compiler, the compiler runs before your program). My point is an aside, merely that you must not assume that dereferencing an invalid pointer will lead to an exception. That's a common misconception. I've no idea about the debugger issue you face.