David Heffernan

Your code looks wrong. You want to write the contents of the rect to the stream, but instead your code tries to write the address of the rect variable. I'd also use WriteBuffer here which will check for errors. Your code ignores any write errors because it doesn't check the return value of Write. WriteBuffer does that for you. Replace With m.WriteBuffer(r, SizeOf(r));

Do you have a specification for what these s printer expects to receive?

It's going to be alignment of the local variables. They need to be aligned. You probably need to allocate an array with 12 bytes in (well, 11 will do), and do some bit twiddling to get the addresses within that array that are aligned. EDIT: Actually, I'm not sure of that now. I guess the two by value params are passed on the stack so I'm probably talking rubbish.

@Ian Branch I didn't understand the advice in the post that you appear to be using as your reference. I'm not at all sure thelat you will end up with better code or better understanding by following that advice.

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.