David Heffernan

Just so long as VS Code doesn't auto uninstall every fortnight like it does with me......

At the start of this thread you said that the data was binary. Now you say it is ASCII. Hard to give advice on this basis.

Would be perverse to use 16 bit Char to store 8 bit data. In terms of performance byte strings and byte arrays are similar but if anything byte arrays will be faster. Precisely because they don't have coy on write. No idea why you thing strings perform better. My guess is that your antipathy to byte arrays is a hangover from the legacy Delphi anti pattern that byte arrays are handled as strings.

Flashing can be quite visually aggressive. It is often preferable to highlight a control in some other way.

In the long run it will be less efficient to continue using these bridges.

I can't understand why you would. Aren't you likely just to end up changing your code for no reason, given that the defect is almost certainly not in your compression library?

It's pretty bad advice. Changing algorithm and implementation without any justification or rationale. Seems like you are advocating trying libraries at random. If every time you encounter an issue you replace the lirbsry, after a while you'll have run out of libraries.

They are. That's the a very plausible explanation. File corruption is something that does happen. You'll want to reproduce the issue before trying to solve the problem. And if it is file corruption then the solution is somebody else's problem.

How did you diagnose that the defect was in ZCompressStream or ZCompressStream?

As usual the most simple explanation was the answer. If a string variable is empty then the obvious explanation is that you either assigned it to be empty, or didn't assign it at all.

Kind of odd that you wouldn't just use a byte, TBytes.

Make a minimal reproduction. FastMM reports leaks only in the delphi heap. madExcept reports those leaks and also leaks in many other system resources.

Websearch took me here https://delphi.fandom.com/wiki/Delphi_Release_Dates

Imagine if you have users with names that don't begin with one of the 26 letters used in the English language? What you should do is abandon this UI approach and let the user type.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Breakpoint_List_Window

Asker seems to want to remove certain valid UTF8 sequences..... So this won't help. Nobody can help with no clear spec.

We've all done it. It never works out.

There's a lot of noise in here. It seems you don't really understand where these characters are coming from and are in trial and error programming mode. The advice from the wise heads here is to understand what is going on, and then work out how to tackle it. You don't seem to want to heed that advice. That's fine, it's your choice. But we don't need a blow by blow account of your trial and error coding. That's only meaningful to you.

REMOVED, sorry, was dupe

Yes that is correct. My argument stands. Copying the full record into a local is only expensive (compared to reading a value from the record in-situ in the array) if the record is large. For a small record, copying a handful of bytes costs no more than reading even a single byte. I'm arguing against your claim that there would be a performance hit using a for in loop even for small records. For large records there will be a hit. Not for small records.

No. Because when you iterate over an array, you typically don't read all of the content of each item. Imagine that all you do is look inside each record for an integer ID. If the record is huge, then you can just read a single integer, and move on, if using a classic for loop with an array of record. But if you use a for in loop you have to copy the entire record before reading the single integer ID. That's wasteful. In the case of a smaller record, let's say small enough to fit into a cache line, then reading an integer from the record has the essentially same cost as copying the entire record and then picking out the integer. So the trade off depends hugely on the size of the record, and what proportion of it you actually need to access.

Better hope that there are no line breaks .....

Why would there be an issue for small records? Presumably you are iterating over the array because you want to look at the content of the record. For a small enough record, there won't be any difference in perf between reading a field and copying the entire record.

Your problem is not how to remove characters, it is to work out what characters are to be removed. As is so often the case, the hardest part of any programming tasks is determining the correct specification.

The hardware is designed to handle indexed access efficiently. I've seen plenty of cases where incrementing a pointer inside the loop is slower. After all, you have an extra variable that needs to be incremented. Hard to see why that would be faster. No. The memory access pattern is identical. It's just a sequential pass across the array.