David Heffernan

I guess if there are no firm rules on the expected behaviour, then that makes it easier to write faster code.

Do you have a specification about what you want the function to do? It seems like you don't mind.

One of the big issues with heap allocation comes when you have multi threaded code. If your benchmark doesn't test that and you do have multi threaded code, then your benchmark is likely not very useful.

The simple solution is to put this code in a DLL. Use a side by side assembly manifest to make it self contained.

I'd design the code not to use global vars.

Isn't this the section that is not picked up when linking 64 bit .obj files? Hence leading to problems (like instant process termination) when an exception occurs in such linked code. Or have Emba addressed that in more recent releases?

The code is something of a disaster zone. That leak looks dire. If the component contains this, then who knows what else is there! As for the two minute fix, I gave that above. Replace temp[1] with Pointer(temp)^. But we're still making assumptions because we can't see the exception details.

Why are you using WideString? That's a type for COM interop. Shouldn't temp be string? You leak Buffer. Why do you allocate buffer so that you can copy temp to Buffer and then to reply.buffer? Why not copy direct? Why use Move and CopyMemory? They do the same job. Pick one and use it consistently. What do you do to defend against buffer overrun of reply.buffer? If your code raises an exception, that exception is raised at a specific line, and has a specific message. That information is useful. That you didn't include it in the post suggests that you have not studied it in detail. I bet that it tells you information that would help you understand. And certainly would help us understand. What is that information? The blanket exception handler also looks pretty nasty. That's going to convert all exceptions, no matter how they arise, in to the same error condition. We can guess that temp[1] trips up range checking. But the exception message would remove any need for guessing. Btw, you fix that by using Pointer(temp)^ in place of temp[1].

I don't think @Der schöne Günther was doubting you, just noting that what you were doing seemed correct. Can you make an MCVE and submit a report to Quality Portal?

The code in the original post doesn't. Kinda makes a difference. Still, it's not an important difference as it happens. You have no real need for a hash table based loopup. An array is fine for lookup. You can then use sets additionally.

FWIW, my current codebase has this: procedure TOrcForm.DestroyWindowHandle; // DestroyWnd is not called from the form destructor, so we override DestroyWindowHandle instead begin FreeAndNil(FDropTarget); WTSUnRegisterSessionNotification(WindowHandle); inherited; end; So I guess that's why I said "it rings some bells" in an earlier post.

The point is that many Delphi developers use double buffering to solve problems with flickering when resizing, rather than solving the root cause of the flickering. My experience of double buffering is that whilst it might deal with flickering, it also introduces its own problems. For instance, it changes the appearance of your program if you are using the Windows theme. I don't want that. So I don't use double buffering. And I don't have flicker on resize.

Really? That's upsetting. Although it rings some bells. But it won't matter here because process termination will lead to the system tidying up. Ill have a look tomorrow.

This code fails under VCL window recreation. Hence the Emba code. My answer to this old SO question presents a different way that may be simpler in the long run. https://stackoverflow.com/q/4854534/505088

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.