David Heffernan

It's quite possible to solve your problem, but what you are proposing is not the solution. Solve your problem by responding to the underlying messages. If you have issues with flicker, they can doubtless be solved.

This looks badly wrong to me. What problem are you trying to fix?

Do you observe incorrect behaviour of your program?

This provides no clarification to me. Now I think I have no idea what you are asking.

You can't declare an encoding instance to be a default parameter value because it is not a constant, never mind a true constant. Hence the compiler error. So you have to resort to overloaded methods. Declare one method that accepts an encoding parameter. And another that does not. From that second overload call the first passing your chosen default encoding.

Default values need to be true constants. This is not. You are confusing default encoding with default parameter value.

Not needed. Really not a great idea to suggest needless actions with no basis in fact. Just spreads FUD.

When the debugger evaluates some variables to display values in the debugger it often leaks memory. This is a defect with the debugger. The code here does not leak. Any reported leaks are due the debugger. I see this very often with property getter functions that return strings. The debugger calls the function, creating a new string. But then the debugger fails to destroy the string. Leak.

Why did you choose hex? Isn't base64 a better choice?

Seems odd. Why don't you return binary?

It is not interesting. Also, no guarantee that invalid pointer leads to access violation. Corrupted data is perfectly possible.

There's a huge difference between making an unintended mistake after having done your best not to, and intentionally harming. It's surely not difficult to see.

Tell that to the lawyers. Of course it matters.

Seconded.

FlexNet

VTune works well. AQTime was an unmitigated AV fest when I last tried it.

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.