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.

Yeah, you are wrong. Dereferencing an invalid pointer could result in anything. Exception. Code apparently working. Or anything else really.

I called it like this: procedure TPythonEngine.Execute(const Code: PAnsiChar; const globals, locals: IPyDictionary); var retval: PPyObjectRef; begin retval := PyRun_StringFlags(Code, Py_file_input, globals.Ref, locals.Ref, nil); CheckError(Assigned(retval)); DecRef(retval); end; I passed exit() in via the Code argument, and empty dicts in globals and locals. retval comes back nil and CheckError is my function to extract tracebacks. I know we looked at way back when we first embedded Python. I honestly don't recall the details. I think some part of the decision will be my own fastidiousness to have total control over everything, and as you know P4D has a huge range of functionality. We only scratch at the surface of what P4D can do. Our usage is a finite element structural engineering code which allows users to customise some parts of the calculation and post-processing by calling Python code that they provide. So we just need to create instances, populate attributes, and call the user function passing in those instances. Then we need to read out the attributes from those instances after the user script has run. It's such a tiny part of what P4D offers, that we just did it ourself. The way our wrapper exposes Python is much closer to the metal than P4D I believe. We use interfaces to wrap Python objects, and because they are also reference counter, that fits really nicely with the Python ref count. When our implementing wrapper objects are destroyed (because the Delphi ref count goes to zero), we just call Py_DecRef on the underlying Python object. I seem to recall that in P4D client code you sometimes have to deal with the Python ref code, but we've been able to hide that from our client code. Anyway, embedded Python is a truly remarkable achievement, and P4D is clearly a fantastic library. Our software would be far poorer without embedded Python.

You have not defined a type there. You've defined an alias. That's a crucial distinction that is very relevant for the behaviour you observe. I don't really understand what your alias is buying you. I'd prefer to be explicit here.

If you read @pyscripter's comment you will realise that what you need is impossible. Usually in the face of impossibility it's time to look for other approaches. I was able to catch SystemExit when I ran a single line of code using PyRun_StringFlags but I guess you are executing a module and I suppose that is treated differently. Anyway, it's time to recalibrate expectations.

It's better to fix the original code. Either by using ReadBuffer, or by comparing Read return value against the number of bytes requested. Is this really Embarcadero code? Hard to believe they'd write Readed!

Use websearch. That's all we would do.

This code can fall into an in infinite loop if Stream.Read fails

Yes, but it easier just to use a command line tool to do this. You don't need any components. Delphi comes with a library of hash functions. That doesn't make much sense. A hash function is a function that maps an arbitrary length array of bytes to a fixed length array of bytes. Your image file is the input to the hash function. Multiple different inputs can yield the same has for fairly obvious reasons. Reading about hash functions would be useful for you.

You mean a nullable type? There are lots of implementations. Spring has one but there are plenty more.

We are going round in circles. I wouldn't call exit if I wanted the process not to be terminated. I can't for the life of me imagine why you want to call exit otherwise. That said, in my own wrapper of embedded Python, if I call PyRun_StringFlags passing exit() then it doesn't terminate the process, and the call returns an error with a traceback. So maybe python4delphi is doing something else. Whilst I'm familiar with calling embedded Python from Delphi, I use my own wrapper. You probably need specific python4delphi knowledge, but you asked the question in the VCL sub-forum by mistake. Perhaps you need to ask a mod to migrate it?