David Heffernan

You clearly don't have a robust understanding of how threads work. The outer caller of SendMessage blocks until that call returns.

The code in the original post, using SendMessage is fine. It passes a pointer to the first character of the string, and the call to SendMessage doesn't return until the message has been fully processed.

This is completely wrong.

Yes it is documented in the remarks section of the SendMessage documentation. Parameters are marshaled for messages known by the system. A good example is WM_COPY. The data that you pass to that message is marshaled to the target process, because the system knows its structure. For user defined messages, no marshaling of parameters is performed.

Do you understand that what you want is not supported, and any attempt to implement it will inevitably rely on implementation details that are subject to change? If you find the level of service that you are receiving from this site to be below expectations that I can only apologise and hope you have better luck elsewhere.

@Darian Miller Anders is right, there is a race here. You don't need to run any code to see it. However, its all moot because this code isn't that which the asker is using. The asker's code handles the text fine.

The code in the original post uses SendMessage. Which is synchronous. What you say would be true if you used PostMessage. But that is not what is happening here. I guess that you were making that second point on the assumption that PostMessage had to be used, which I didn't pick up. Debugging with tiny excerpts of code is kinda pointless. The asker can obtain a stack trace and take it from there.

Total obfuscation here. Just because it exists doesn't mean you should use it.

Wouldn't this be better submitted as an issue on the github repo? That way there's a record of it for other users of the project.

Why do you call ProcessMessages? And you say there are AVs but you don't have any information. The two addresses are critical, both the code address and the data address. And the call stack will be vital. Aren't you using madExcept or similar? Or if you have this under the debugger then you inspect call stack when the AV is raised.

I'm afraid that both the points stated here are factually incorrect. SendMessage synchronously sends a message to a window. The code is executed by the thread that owns that window. Secondly, there is no reason why code in one thread should not operate on a string variable allocated in a different thread. That's not even what's going on anyway. It's just a pointer to null terminated character array. And the message handler receives that and makes a new string. No problem there.

https://stackoverflow.com/questions/61256698/show-tray-icon-always-visible-on-the-task-bar Is this you asking?

This isn't really a Delphi issue. You'd be better off searching more widely for the hacks that you desire. Be prepared for them to be brittle.

It's a mess when you have Scaled set to True and you design on different machines with different DPI settings. Always has been. At my office the rule is that forms are always designed at 96 DPI to avoid such issues.

Is it unreasonable to expect that programmers have knowledge and skill?

That post is worthless. Best to ignore it.

Please provide a minimal project, and describe the display settings on your machine.

What I can't understand is why you would ever need to call such a function. Broadly, you never ask if a file is in use an any one moment. You try to do something with a file, and then handle the scenario that it fails due to being open.

That doesn't make a lot of sense. What is the successor of a collection. Perhaps you mean the successor of a member of a collection. But that only makes sense in the context of the collection.

For an array indexed access is usually fastest. Delphi RTL enumerators are often sub optimal. I mean, heap allocation to iterate a collection ffs.

> Is a standard comment before each procedure implementation useful? No

High is fine for an array. Pred is a stupid way to write Count - 1. I mean, you aren't proposing writing Pred(Length(arr)) are you.

No. It's pointless verbiage. Use List.Count - 1

The difference is that Pred(...) is verbose and opaque.

That's true type not open type