David Heffernan

I've really not found a reliable profiler for x64 windows code. Have I missed anything?

I've had mixed results with that. What we really really need is a way to generate PDB files. If only Emba would add that functionality.

Do this for both 32 and 64 bit. Just because you might get away with it in 32 bit for now, doesn't mean you always will. And if your app doesn't need floating point exceptions unmasked then mask them. Have consistency between 32 and 64 bit.

Isn't this just the age old issue that Delphi's RTL unmasks floating point hardware exceptions, but most other tools (including the MS tools) mask them. So the ActiveX control that implements the embedded browser expects floating point hardware exceptions to be masked and is caught out by your host having unmasked them. Resolve the problem in the traditional way by masking floating point hardware exceptions. There are countless SO posts on this subject which will show you how to do this.

The code in the original post that uses SendMessage to send a string is correct. Your problem is elsewhere. A madExcept bug report at the point of the exception will tell you more.

A big part of your problem is trying stuff at random without any understanding of the reason why. You say that you find windows a swampy mess, but the code you presented here can be reasoned with quite easily if one has the knowledge, and it isn't that advanced. Unfortunately quite aot of the "advice" you have received has been incorrect. The only way for you to make progress is to stop guessing and trying random suggestions from people who don't understand the area. Get a stack trace with madExcept. It takes little time to add that.

Yes, sorry

It doesn't matter. The original call, made from the thread does not return until that message has been processed. If the code in the main thread, that processes the sent message, sends or posts messages, that's fine. I don't think that we should hijack this thread anymore.

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.