David Heffernan

I only use WriteBuffer myself, FWIW. WriteData was a bad mistake.

Not really namespaces as would be useful in this context.

You can license mormot under MPL which is fine for use in a commercial product.

No. I would just call WriteBuffer and ReadBuffer which take care of error handling for you. Sure, but lots of stream code is written against TStream so that it can be more useful. So that it is agnostic to which stream type is being used. So if you get in the habit of using WriteBuffer and ReadBuffer (that's why they exist remember, you were always meant to call them rather than Write and Read) then you have no problems.

Double buffering is absolutely one of the things that you don't do when over RDP. Because then you give up app the benefit of transmitting the logical drawing instructions and instead have to send raster images. But I wouldn't say RDP is double buffering. You don't draw to off screen bitmap and the flip it or blit it. If you want to draw text, you send the text and instructions of where to draw it, and then the actual rendering happens at the other side. But yeah, advice to double buffer is wrong. Correct advice is the opposite. Don't ever double buffer in a remote session. More on that here: https://devblogs.microsoft.com/oldnewthing/20060103-12/?p=32793 This may come as a shock to a lot of Delphi devs for whom the standard reaction to flicker seems to be to enabled DoubleBuffered on the form/control.

I am still amazed at how common it seems to be for people to call Write and Read without checking for errors. We should set a better example.

Don't these printers all require different input? Or am I missing something?

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.